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Training  of  command,  control,  and  communication  (C3)  skills  in  the 
Army  has  historically  been  conducted  in  a  field  environment  using  actual 
equipment.  The  cost  of  such  exercises  is  already  very  high  and  will 
continue  to  mount  as  new,  more  sophisticated,  more  costly  weaponry  and 
support  systems  are  taken  into  the  inventory.  Basic  skills  are  learned 
in  a  classroom  environment  (the  "crawl"  phase  of  training)  and  then 
Integrated  and  practiced  in  these  field  exercises  (the  "run"  phase  of 
training) .  What  has  been  missing  is  a  useful  method  of  practicing  these 
C3  skills  during  a  training  activity  that  bridges  the  crawl  and  run 
phases,  a  "walk"  phase.  Such  a  training  method  would  allow  soldiers  to 
make  the  mistakes  characteristic  of  soldiers  new  to  the  task  in  a  low 
cost  environment — low  cost  monetarily  as  well  as  In  terms  of  equipment 
and  terrain  damage. 

ARI  has  been  searching  for  such  a  method  and  has  developed  a  battle 
simulation  that  can  be  used  to  conduct  research  on  this  training 
problem.  This  battle  simulation,  called  SIMCAT  (Simulation  in  Combined 
Arms  Training) ,  will  provide  a  vehicle  for  conducting  research  on  C3 
training  and  performance  in  the  context  of  the  armor  platoon.  SIMCAT 
will  be  used  to  determine  how  subordinate  leaders  in  armor  units  can 
learn  to  command  and  control  their  units  while  still  in  the  classroom, 
thereby  reducing  the  amount  of  time  (and  money)  required  for  C3  training 
in  the  field. 

This  report  describes  how  the  functional  requirements  for  SIMCAT 
were  developed,  lays  out  those  functional  requirements  in  a  new  and 
innovative  way  so  that  hardware  and  software  development  flows  easily 
from  them,  and  describes  the  hardware  solution  resulting  from  the 
requirements . 
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DEVELOPMENT  OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMULATION 
IN  COMBINED  ARMS  TRAINING  (SIMCAT) 


EXECUTIVE  SUMMARY 


Requirement : 

The  Army's  Airland  Battle  doctrine  has  increased  the  command, 
control,  and  communication  responsibilities  of  subordinate  commanders 
and  requires  these  commanders  to  make  rapid  decisions  in  combat.  While 
classroom  training  provides  insufficient  practice  in  command  and  con¬ 
trol,  field  training  is  both  a  costly  and  Inefficient  way  to  learn  basic 
C3  skills.  One  solution  to  this  problem  is  to  develop  a  low  cost  battle 
simulation  that  could  serve  as  a  link  between  the  classroom  and  the 
field.  Skills  that  are  introduced  in  the  classroom  could  be  practiced 
on  the  battle  simulation  and  later  refined  during  practice  in  the  field. 
It  is  the  purpose  of  this  project  to  explore  this  approach  to  training 
by  developing  a  computer  supported  battle  simulation,  SIMCAT  (Simulation 
for  Combined  Arms  Training) ,  that  can  be  used  as  a  research  vehicle  to 
determine  how  battle  simulations  can  be  used  to  train  the  subordinate 
commanders  in  a  tank  platoon  (i.e.,  platoon  leader,  platoon  sergeant, 
and  tank  commanders)  to  perform  the  C3  skills  required  for  effective 
coordination  in  combined  arms  operations. 


Procedure: 

The  functional  requirements  for  SIMCAT  were  derived  from  a  variety 
of  sources  including  representative  scenarios.  Army  Training  and  Evalua¬ 
tion  Programs  (ARTEPs) ,  situational  training  exercise  (STXs) ,  and  battle 
drills.  These  requirements  defined  the  processes  and  representations 
that  SIMCAT  must  satisfy  to  achieve  its  intended  training  goals. 

Included  among  the  categories  of  functional  requirements  were  those 
pertaining  to  terrain,  movement,  detection/identification,  engagement, 
and  indirect  fire.  As  the  functional  requirements  were  being  prepared, 
information  was  obtained  on  the  hardware,  software,  and  peripherals  that 
would  be  required  to  support  the  functional  requirements. 


Findings : 


SIMCAT  will  consist  of  six  networked  microcomputers  (four  trainee 

stations,  and  stations  for  the  opposing  force  and  the  controller/ 
trainer)  that  will  provide  audio  visual  cues  inherent  in  tactical 
situations  to  all  simulation  participants  using  videodiscs  and  computer 
generated  graphics.  Each  trainee  will  be  provided  a  display  showing  an 
overhead  view  of  a  map.  Graphic  representations  of  friendly  and  enemy 
weapon  systems  will  be  superimposed  upon  the  map.  Factors  such  as  line 
of  sight,  distance,  and  obscurants  will  be  taken  into  account  in  deter¬ 
mining  target  identification.  Voice  synthesis  and  speech  recognition 


vii 


technologies  will  permit  trainees  to  control  tank  movement  and  firing 
using  normal  communications  protocols.  Playback  capabilities  and  simu¬ 
lation  summaries  will  enable  the  controller/trainer  to  provide  feedback 
to  trainees. 


Utilization  of  Findings: 

When  completed,  SIMCAT  will  serve  as  a  research  vehicle  to  investi¬ 
gate  how  a  computer  supported  battle  simulation  can  be  used  as  a  link 
between  the  classroom  and  the  field  enabling  students  in  officer  and 
noncommissioned  officer  courses  to  practice  command,  control,  and  com¬ 
munications  skills  before  participating  in  situational  training 
exercises.  It  will  also  be  usable  to  conduct  research  on  how  tank  com¬ 
manders,  platoon  sergeants,  and  platoon  leaders  can  practice  these 
skills  in  units  when  training  areas  are  scarce  or  when  resources  such  as 
ammunition  and  fuel  must  be  preserved. 
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DEVELOPMENT  OF  THE  FUNCTIONAL  KE(>UI REMEXTS  FOR  SIMULATION 
IN  COMBINED  ARMS  TRAIN  I  NO  (SI  MO.  AT) 


INTRODUCTION 

Airland  Battle,  the  Army's  doctrine  for  the  mid-1980's,  advocates 
increased  decentralization  of  command  and  control  during  combat.  It  is 
anticipated  that  the  leaders  of  small  units  (e.g.,  squad  leaders, 
platoon  leaders,  company  commanders)  will  have  greater  latitude  in  exer¬ 
cising  the  initiative  during  combat  operations  than  leaders  of  similar 
units  have  had  in  the  past.  This  expectation  is  the  result  of  a  need  to 
maintain  greater  dispersion  among  units  as  a  defense  against  the 
increased  lethality  of  opposing  force  (OPFOR)  weapon  systems,  especially 
NBC  weapons,  and  as  a  consequence  of  OPFOR  interference  in  battlefield 
command  and  control.  As  a  result  of  combat  decentralization,  subordi¬ 
nate  leaders  such  as  tank  commanders,  platoon  leaders,  and  company 
commanders  will  have  greater  command  and  control  responsibilities  than 
their  counterparts  have  had  in  the  past.  Adding  to  these  responsibili¬ 
ties  is  the  doctrinal  requirement  that  subordinate  leaders  exercise 
agility  in  combat  by  making  rapid  decisions  in  order  to  counterbalance 
OPFOR  superiority  in  manpower  and  weaponry. 

Because  of  this  change  in  the  anticipated  combat  role  of  subordi¬ 
nate  leaders,  it  has  become  increasingly  important  that  these  leaders  be 
adequately  trained  in  command,  control,  and  communications  (C3).  In  the 
past  many  command,  control,  and  communications  skills  were  learned 
during  combat  itself.  The  present  battlefield  has  become  so  lethal, 
however,  that  inadequately  trained  soldiers  are  unlikely  to  survive. 
Consequently,  combat,  control,  and  communications  skills  must  be  learned 
to  standard  before  these  soldiers  enter  combat.  This  will  not  only 
increase  the  likelihood  of  survival,  it  will  also  result  In  greater 
synchronization  among  the  different  elements  of  the  unit  during  battle. 
Unfortunately,  while  the  need  for  adequate  C3  training  is  rising,  so  are 
training  costs.  Resources  such  as  fuel,  ammunition,  and  equipment  have 
become  so  expensive  that  training  budgets  have  become  strained.  Adding 
to  the  difficulty  of  providing  adequate  C3  training  are  shortages  of 
training  personnel  and  shortages  of  adequate  training  areas,  particu¬ 
larly  in  Europe. 

Due  to  problems  such  as  these,  the  Army  explored  the  use  of  tacti¬ 
cal  engagement  simulation  training  systems.  One  of  the  earliest  cf 
these  system.-,  SCOPES,  used  inexpensive  hardware  to  enable  two  opposing 
forces  to  actively  engage  one  another  in  a  free-play  environment.  The 
extension  of  SCOPES  from  infantry  platoons  to  armor  units  resulted  in 
REALTRAIN.  These  systems  eventually  evolved  into  MILES  (Multiple  Inte¬ 
grated  Laser  Engagement  System)  in  which  lasers  were  used  to  assess 
battlefield  casualties. 

While  tactical  engagement  simulation  training  systems  eliminated 
the  need  for  ammunition  and  provided  a  mechanism  for  assessing  certain 
aspects  of  performance,  the  implementation  of  these  training  systems 
still  required  extensive  resources  such  as  fuel,  weapon  systems,  and 


training  areas.  Consequently,  the  Army  began  to  explore  the  use  of 
battle  simulations  for  training.  One  of  the  earliest  of  these,  TOX 
(Tactical  Opposition  Exercise) ,  was  a  tactical  game  board  which  has 
since  evolved  from  single  player  versions  to  combined  arms  versions. 

With  the  availability  of  computer  technology,  the  Army  expanded  its 
exploration  of  battle  simulations  with  the  development  of  computer 
supported  simulations  such  as  BABAS  (Battalion  Automated  Battle 
Simulation,  formerly  MACE),  CATTS  (Combined  Arms  Tactical  Training 
Simulation),  and  ARTBASS  (Army  Training  Battle  Simulation).  BABAS  is  a 
battle  simulation  designed  for  training  battalion  commanders  and  their 
staffs  to  exercise  command  and  control  skills  during  combat.  CATTS  and 
ARTBASS,  similarly,  are  battle  simulations  designed  for  training  command 
and  control  skills  at  the  battalion  level.  Other  battle  simulations 
have  also  been  developed  for  leadership  training  at  higher  echelons 
(e.g.,  ARTBASS,  FIRST  BATTLE).  Despite  the  emphasis  that  has  been 
placed  on  the  development  of  battle  simulations  for  training  commanders 
and  staffs  at  battalion  level  and  higher,  relatively  little  effort  has 
been  expended  to  create  battle  simulations  for  training  leaders  at  lower 
echelons.  Those  that  have  been  developed  for  use  at  company  level  or 
lower  (e.g.,  TOX,  Dunn  Kempf) ,  moreover,  have  not  incorporated  computer 
technology.  Because  of  the  lack  of  attention  that  has  been  given  to  the 
use  of  battle  simulations  for  training  command  and  control  skills  at 
lower  echelons,  there  is  a  considerable  gap  between  training  in  the 
classroom  and  training  in  the  field  that  students  find  difficult  to 
cross.  A  properly  designed  battle  simulation  may  readily  meet  this 
need. 

The  potential  value  of  battle  simulations  in  training  becomes 
especially  apparent  when  examining  the  need  for  more  efficient  training 
of  C3  skills  among  the  leaders  assigned  to  tank  platoons.  The  tank 
platoon,  according  to  Division  86  doctrine,  consists  of  four  tanks.  The 
platoon  is  under  the  command  of  a  platoon  leader  who  is  also  the  com¬ 
mander  of  one  of  the  four  tanks.  Assisting  the  platoon  leader  is  a 
platoon  sergeant  who  is  the  commander  of  one  of  the  remaining  three 
tanks.  Each  of  the  remaining  two  tanks  is  under  the  control  of  its  own 
tank  commander.  The  effective  conduct  of  armor  operations  on  the  bat¬ 
tlefield  requires  these  four  leaders  and  their  crews  to  operate  together 
as  an  integral  unit  under  the  command  of  the  platoon  leader. 

At  the  present  time,  the  C3  skills  required  for  effective  coordina¬ 
tion  between  the  platoon  leader,  the  platoon  sergeant,  and  the  two  tank 
commanders  in  a  tank  platoon  are  taught  in  the  classroom  and  trained 
and/or  reinforced  in  the  field.  There  is  no  current  mechanism  that  will 
allow  these  leaders  to  practice  coordination  in  command  and  centre], 
during  institutional  training,  and  it  is  a  typical  observation  during 
field  training  that  these  leaders  have  difficulty  applying  the  training 
they  received  in  the  classroom  to  actual  operations  in  the  field.  While 
these  difficulties  can  be  overcome  eventually  through  practice  and 
repetition  in  the  field,  this  method  of  training  effective  command, 
control,  and  communication  is  obviously  expensive  and  inefficient. 

Given  the  high  costs  of  field  training  and  the  shortage  of  both  training 
sites  and  training  personnel,  it  would  be  much  more  efficient  to  devise 
a  procedure  that  would  enable  the  leaders  in  a  tank  platoon  to  practice 
coordination  before  participating  in  field  exercises.  Once  the  basic 


skills  required  for  effective  coordination  are  adequately  learned  at  low 
cost,  these  skills  can  then  be  refined  in  the  field. 

One  means  by  which  the  leaders  in  a  tank  platoon  may  be  able  to 
practice  basic  skills  before  participating  in  field  exercises  is 
through  the  use  of  a  computer  supported  battle  simulation.  It  is  the 
goal  of  this  project  to  develop  a  prototype  battle  simulation  that  may 
eventually  be  used  for  this  purpose.  This  simulation,  SIMCAT  (Simula¬ 
tion  for  Combined  Arms  Training),  is  being  developed  for  the  U.S.  Army 
Research  Institute  for  the  Behavioral  and  Social  Sciences  (AR1)  by  the 
Human  Resources  Research  Organization  (HumRRO)  with  Perceptronlcs  as  its 
subcontractor.  When  completed,  it  will  be  used  by  ARI  to  conduct 
research  on  how  to  train  C3  skills  in  a  classroom  environment. 

There  are  several  advantages  that  a  computer  supported  battle 
simulation  would  have  over  one  that  is  not  computer  supported.  One 
advantage  is  a  reduction  in  number  of  support  personnel  required  to 
operate  the  simulation.  Host  battle  simulations  are  manpower  intensive 
since  they  require  a  relatively  large  number  of  support  personnel  com¬ 
pared  with  the  number  of  people  who  can  be  trained  on  them.  A  battle 
simulation  can  require  several  controllers  as  well  as  persons  to  control 
movement,  indirect  fire,  and  OPFOR  activities.  Since  many  of  these 
functions  can  be  performed  by  a  computer,  a  reduction  in  support  person¬ 
nel  can  be  achieved  by  using  a  battle  simulation  that  is  computer 
supported.  Another  advantage  of  a  computer  supported  battle  simulation 
is  that  it  allows  the  simulation  to  be  conducted  in  a  closer  approxima¬ 
tion  to  real  time.  In  addition,  a  computer  supported  battle  simulation 
can  provide  for  more  effective  feedback  since  the  data  required  for 
feedback  can  be  collected,  stored,  and  reproduced  using  the  computer. 

The  development  of  SIMCAT  is  taking  place  in  a  sequence  of  six 
tasks.  This  report  describes  the  results  of  the  activities  that  were 
performed  during  the  first  two  tasks.  During  Task  1,  the  functional 
requirements  for  SIMCAT  were  derived  from  a  variety  of  sources  such  as 
task  inventories,  Army  Training  and  Evaluation  Programs  (ARTEPs) ,  and 
situational  training  exercises  (STXs) .  These  requirements  prescribed 
the  specific  processes  and  representations  that  would  have  to  be  incor¬ 
porated  into  SIMCAT  to  enable  it  to  fulfill  its  training  research 
functions.  During  Task  2,  these  functional  requirements  were  used  to 
design  the  resulting  battle  simulation  and  to  identify  the  specific 
hardware  and  software  components  that  would  have  to  be  developed  or 
purchased  in  order  to  develop  a  prototype  version  of  SIMCAT. 

The  functional  requirements  contained  in  this  paper  were  prepared 
by  HumRRO  and  were  provided  to  Perceptronics  to  serve  as  the  basis  for 
selecting  the  hardware  for  SIMCAT  and  for  designing  its  software.  Three 
factors  were  taken  into  account  by  HumRRO  when  preparing  the  functional 
requirements — (1)  the  purpose  for  which  SIMCAT  was  being  developed, 

(2)  the  ceiling  placed  on  the  total  cost  of  the  hardware,  and  (3)  the 
cost  of  developing  the  required  technology.  As  a  result,  functional 
requirements  that  were  judged  consistent  with  SIMCAT 's  purpose  were 
rejected  by  HumRRO  when  either  the  hardware  or  technology  development 
costs  associated  with  them  were  known  to  be  excessive.  Once  the 


functional  requirements  were  provided  to  Perceptronics,  the  same  set  of 
factors  was  again  taken  into  account  during  the  design  of  the  system. 
Thus,  functions  were  not  Implemented  when  the  price  of  the  hardware 
caused  the  system  to  exceed  its  cost  ceiling  or  when  the  cost  of  devel¬ 
oping  the  required  technology  was  excessive.  Consequently,  not  all  of 
the  functions  specified  in  this  report  will  actually  be  Incorporated 
into  SIMCAT,  and  conversely,  SIMCAT  will  contain  functions  that  are  not 
specified  in  this  report. 

The  purpose  of  this  part  of  the  report  is  to  describe  the  func¬ 
tional  requirements  which  served  as  the  basis  for  the  design  and 
development  of  SIMCAT.  Although  SIMCAT  was  designed  after  these 
requirements  were  prepared,  a  description  of  SIMCAT  is  presented  here  to 
enable  the  reader  to  relate  the  functional  requirements  to  the  design  of 
the  system. 

SIMCAT  will  contain  six  stations — four  trainee  stations,  an  OPFOR 
station,  and  a  controller/trainer  station.  Each  station  will  have  a 
display  showing  an  overhead  view  of  a  map.  Instead  of  the  standard 
military  map,  a  nonmilitary  version  containing  fewer  navigational  cues 
will  be  displayed.  The  display  on  two  of  the  four  trainee  stations  will 
be  reversed  so  that  correct  procedures  will  be  required  for  proper  navi¬ 
gation. 

Superimposed  upon  each  display  will  be  graphic  representations  or 
symbologies  of  friendly  tanks  controlled  by  the  trainees  and  of  enemy 
tanks  and  enemy  infantry  fighting  vehicles  controlled  by  an  OPFOR 
player.  Each  trainee  will  be  able  to  see  symbologies  representing  his 
own  tank  and  other  weapon  systems  that  are  in  his  line  of  sight.  Each 
trainee  will  be  able  to  select  from  among  three  displays — a  close-up 
view  which  will  maximize  terrain  detail,  a  far  view  which  will  maximize 
the  area  of  the  display,  and  an  intermediate  view.  The  OPFOR  display 
will  show  graphic  representations  of  all  OPFOR  weapon  systems  and  all 
friendly  tanks  that  are  within  line  of  sight  of  an  OPFOR  weapon  system. 
The  display  available  for  the  controller/trainer  will  show  all  weapon 
systems  regardless  of  line  of  sight. 

Each  trainee  will  be  able  to  move  his  own  tank,  rotate  its  turret, 
communicate,  generate  smoke,  and  fire  two  of  the  tank's  weapons — the 
main  gun  and  the  coaxial  machlnegun.  The  trainee  will  be  able  to  move 
his  tank  and  fire  its  weapons  using  voice  commands  as  if  an  actual  crew 
were  present.  The  system  will  recognize  certain  commands  and  execute 
them  accordingly.  When  a  trainee  issues  a  fire  command,  the  system  will 
execute  the  command  and  automatically  determine  whether  or  not  the 
target  if;  hit.  If  the  target  is  destroyed,  this  information  will  be 
displayed  to  each  trainee  in  line  of  sight  of  the  destroyed  target,  to 
the  OPFOR,  and  to  the  controller/trainer.  The  OPFOR  will  also  be  able 
to  control  the  movement  and  firing  of  his  weapon  systems  and  will  be 
able  to  implement  automated  control  of  movement  and  firing  to  compensate 
for  the  greater  number  of  vehicles  and  weapon  systems  under  his  control. 
Under  automatic  control,  the  OPFOR  will  be  able  to  select  a  destination 
and  the  system  will  automatically  move  the  OPFOR  weapon  systems  along  an 
appropriate  route.  If  the  OPFOR  decides  to  select  his  own  movement 
route,  he  will  be  able  to  do  so  by  designating  points  along  the  route  he 


wishes  to  travel.  The  OPFOR  will  be  able  to  fire  each  weapon  system 
manually  or  have  them  fire  automatically  using  realistic  opening  times 
and  hit  probabilities. 

Each  trainee  will  bring  his  own  CVC  helmet  to  SIMCAT.  He  will 
communicate  to  his  crew  on  an  intercom  although  no  crewmembers  will 
actually  be  present.  SIMCAT  will  react  to  selected  commands  from  the 
trainee  and,  when  appropriate,  will  respond.  Communications  among  the 
trainees  will  be  possible  on  a  platoon  net  or  with  hand  and  arm  signals. 
If  a  trainee  communicates  using  hand  and  arm  signals,  a  graphic 
representation  of  the  signal  will  appear  on  the  display  of  the  other 
trainees  who  are  in  line  of  sight  with  the  tank  issuing  the  signal.  The 
platoon  leader  and  platoon  sergeant  will  be  able  to  communicate  to  the 
company  commander  and  to  the  FIST  FO  on  the  company  net.  The  platoon 
leader  or  the  platoon  sergeant  will  be  able  to  use  this  net  to  call  for 
indirect  fire.  The  system  will  provide  Indirect  fire  and  adjust  it 
automatically.  Communications  will  also  be  possible  between  the 
controller/trainer  and  each  trainee  and  between  the  controller/trainer 
and  the  OPFOR.  The  controller/ trainer  will  play  the  role  of  the  company 
commander  and  Che  FIST  FO  in  communicating  with  the  trainees. 

The  controller/trainer  will  be  able  to  monitor  and  play  back  all 
events  and  communications.  A  built-in  feedback  system  will  provide  the 
controller/  trainer  with  data  that  can  be  used  for  providing  feedback. 
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TASK  I:  APPROACH  TO  THE  DEVELOPMENT 
OF  THE  FUNCTIONAL  REQUIREMENTS  FOR  SIMCAT 


Approach 


Before  attempting  to  identify  the  functional  requirements  for 
SIMCAT,  it  was  necessary  to  clarify  the  meaning  of  the  term  "functional 
requirements."  In  this  document,  functional  requirements  will  be 
defined  as  the  processes  and  representations  that  the  SIMCAT  system  must 
satisfy  to  achieve  its  intended  training  goals.  Processes  are  those 
functions  that  are  necessary  to  permit  tank  platoon  leaders,  platoon 
sergeants,  and  tank  commanders  to  perform  tasks  normally  associated  with 
the  operation  of  a  tank  in  a  field  environment.  Representations  are  the 
visual  and  auditory  stimuli  to  which  tank  platoon  leadership  personnel 
would  normally  be  exposed  in  executing  tactical  activities  in  a  field 
environment. 

SIMCAT  functional  requirements  could  be  derived  from  a  variety  of 
sources  such  as  training  objectives,  representative  tactical  scenarios, 
task  inventories.  Army  Training  and  Evaluation  Programs  (ARTEPs) ,  situa¬ 
tional  training  exercises  (STXs),  or  battle  drills.  Adopting  the 
functional  requirements  from  any  single  source  would  have  been  risky 
because  of  the  difficulty  involved  in  determining  the  degree  to  which  a 
set  of  scenarios  is  representative  of  combined  arms  operations  or  a  task 
inventory  is  complete.  For  this  reason,  it  was  decided  to  draw  upon  all 
these  sources  collectively  to  synthesize  the  functional  requirements. 

The  sources  included  the  following: 

ARTEP  71-2,  Army  Training  and  Evaluation  Program 
for  Mechanized  Infantry/Tank  Task  Force,  23  November 
1981. 

19K10-40  Task  Documentation  (Directorate  of  Training 
and  Doctrine,  U.S.  Army  Armor  School),  25  January  1983. 

Program  of  Instruction,  Basic  Noncommissioned 
Officer  Course  (BNCOC)  19K  Ml  Abrams  (US  Army  Armor 
School),  June  1983. 

FM  17-15  (Test) ,  The  Division  86  Tank  Platoon, 

April  1983. 

IT  71-1/2,  Division  86.  Volume  II:  Company  and 
Platoon,  March  1982. 

Once  it  had  been  determined  from  which  data  sources  the  functional 
requirements  were  to  be  derived,  a  starting  point  had  to  be  identified. 
It  was  agreed  that  three  representative  scenarios  would  serve  as  this 
starting  point.  Two  of  these  scenarios  were  then  developed  (hasty 
attack  and  movement-to-contact)  and  an  outline  of  the  defend  battle 
position  scenario  was  formulated.  Each  scenario  reflected  SIMCAT's 
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training  goals,  armor  platoon  task  inventories,  and  doctrine,  as  well  as 
ARTEPs  and  training  techniques  (e.g.,  battle  drills,  STXs) . 

With  the  initial  focus  on  the  scenarios,  the  functional  require¬ 
ments  for  SIMCAT  began  to  emerge.  However,  the  scenarios  could  not  be 
viewed  in  isolation.  Although  they  were  based  upon  the  aforementioned 
data  sources  (e.g.,  task  inventories,  ARTEPs,  etc.),  these  sources  had 
to  be  referenced  repeatedly  in  conjunction  with  the  scenarios  before 
functional  requirements  could  be  determined.  This  was  because  the 
process  and  representation  requirements  could  not  be  derived  from  the 
scenarios  alone.  An  example  of  this  occurred  when  a  scenario  required 
an  Ml  tank  to  engage  an  opposition  force  (OPFOR)  tank.  Although  various 
conditional  factors  were  specified  (such  as  the  locations  of  the 
vehicles) ,  it  could  not  be  determined  from  the  scenario  alone  what 
specific  SIMCAT  functional  requirements  were  necessary.  As  a  result, 
attention  had  to  be  focused  on  the  other  data  sources  (in  this  case, 
task  Inventories  and  FMs) .  The  specific  processes  (e.g.,  movement, 
firing  main  gun)  and  representations  (e.g.,  weapon  signatures)  that 
SIMCAT  had  to  satisfy  to  accommodate  the  engagement  described  in  the 
scenario  were  determined  from  these  data  sources.  The  result  was  an 
iterative,  cyclic,  and  deductive  procedure  or  approach  to  identifying 
SIMCAT' s  functional  requirements. 

Following  initial  review  of  the  scenarios  and  other  relevant  data 
sources,  ten  categories  of  functional  requirements  were  identified  (see 
section  that  follows).  Once  this  was  done,  it  was  then  necessary  to 
prepare  each  functional  requirement  in  detail.  During  this  process, 
several  questions  surfaced  repeatedly  which  dictated  the  need  to 
establish  some  guidelines  in  considering  functional  requirements. 
Specifically,  the  following  guidelines  were  adopted: 

•  The  80%  Solution  -  It  was  realized  at  the  onset  that  SIMCAT 
could  not  accommodate  all  possible  conditions  experienced 
by  armor  platoons  on  the  battlefield.  Therefore,  it  was 
decided  that  the  focus  would  be  on  conditions  that  were  the 
rule  rather  than  exceptions  to  the  rule.  Thus  it  was 
arbitrarily  decided  that  a  condition  must  have  a  high  prob¬ 
ability  of  occurring  on  the  battlefield  In  order  to  be 
accommodated  by  the  functional  requirements. 

•  Cost  Constraints  -  Robust  research  practice  would  dictate 
that  the  functional  requirements  for  SIMCAT  be  determined 

primarily  on  the  basis  of  its  training  goals.  Reality, 
he>  .  dictated  limits  to  initial  hardware  corf  1rur.it ion 

CC:  *-  -  ■  AY.  Given  that  the  costs  associated  with  a 

I  functional  requirement  could  be  estimated  at  the  time  it 

was  identified,  these  costs  could  not  be  ignored.  There¬ 
fore,  cost  constraints  were  considered  and  any  functional 
requirement  which  would  have  necessitated  a  prohibitive 
|  expenditure  was  disregarded. 

i 

J  •  Training  Focus  -  Since  SIMCAT  is  to  serve  initially  as  a 

i  research  vehicle  on  training  tank  platoon  leadership,  it 

]  constantly  had  to  be  kept  in  mind  that  SIMCAT  was  not  to 

I 
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serve  as  either  a  tank  gunnery  or  crew  trainer.  Gunnery 
and  crew-related  tasks  and  their  associated  functional 
requirements,  therefore,  were  neither  a  primary  concern 
nor,  in  many  cases,  even  desirable.1  For  example,  a  TC  has 
the  option  of  sighting  and  firing  the  main  gun.  No  func¬ 
tional  requirements  were  identified  for  this  activity  for 
two  reasons.  First,  sighting  and  firing  the  main  gun  was 
related  to  tank  gunnery  (a  training  subject  in  its  own 
right).  Second,  since  the  gunner  normally  fires  the  main 
gun,  the  80X  solution  was  applied  and  the  functional 
requirements  attending  TC  firing  were  dismissed. 

•  System  Design  -  The  functional  requirements  were  to  be 
restricted  originally  to  the  processes  and  representations 
that  SIMCAT  must  satisfy  to  achieve  its  training  research 
goals.  The  hardware  and/or  software  requirements  were  to 
be  neither  stated  nor  implied.  However,  some  functional 
requirements  dictated  obvious  hardware/software  require¬ 
ments.  Where  this  occurred,  these  requirements  were 
specified.  As  an  example,  one  situation  arose  in  which  the 
only  way  that  a  particular  set  of  functional  requirements 
could  be  satisfied  was  through  voice  synthesis  and  speech 
recognition.  Taking  into  consideration  the  fidelity 
requirements,  the  burden  placed  on  the  SIMCAT  controller/ 
trainer  position,  and  the  cost,  voice  technology  wa6  deemed 
the  only  feasible  manner  in  which  a  particular  set  of 
functional  requirements  could  be  satisfied.  Rather  than 
expending  the  effort  that  would  have  been  required  to 
Identify  functions  from  which  one  would  determine  a  need 
for  voice  synthesis/recognition,  this  requirement  was 
stated  directly. 

•  Fidelity  -  If  SIMCAT  could  replicate  a  real  battlefield 
environment  (i.e. ,  achieve  100  percent  fidelity) ,  one  could 
be  assured  it  would  satisfy  its  research  requirements  and 
all  current  as  well  as  future  training  requirements. 
However,  even  if  such  a  system  were  technologically 
feasible,  the  cost  would  be  prohibitive.  Therefore, 
fidelity  requirements  were  considered  on  a  case-by-case 
basis  as  the  functional  requirements  were  developed. 
Although  the  level  of  fidelity  required  in  a  simulation  has 
been  the  subject  of  much  debate  in  research,  satisfactory 
criteria  or  methodologies  for  determining  simulation 
fidelity  requirement:  have  yet  to  be  developed.  However, 
since  the  issue  of  fidelity  could  not  be  avoided  in 
defining  the  functional  requirements  for  SIMCAT,  sub¬ 
jective,  but  sound,  fidelity  criteria  (based  primarily  on 
cost  constraints,  technological  feasibility,  and  stated  or 
implied  training  goals)  were  applied. 


This  is  not  to  say  gunnery-  and  crew-related  activities  were  totally 
ignored.  However,  they  were  addressed  only  to  the  degree  that  they 
contributed  to  or  detracted  from  the  fidelity  of  a  TC's  C3  activities. 


Analysis  of  the  Functional  Requirements 
for  SIMCAT 


The  functional  requirements  contained  in  this  document  were 
analyzed  Individually  and  collectively  for  several  purposes.  Specifi¬ 
cally,  these  analyses  determined: 

•  Availability  of  Existing  and  Alternative  Technologies  - 
Here  it  was  determined  which  hardware  technologies, 
software  technologies,  or  combinations  thereof  currently 
exist  that  could  satisfy  each  functional  requirement. 

Alternative  technologies  (each  resulting  in  varying  degrees 
of  fidelity)  that  could  be  used  for  satisfying  each  set  of 
functional  requirements  were  Identified  and  documented. 

•  Cost  -  The  costs  associated  with  each  technology  alterna¬ 
tive  identified  were  determined  and  documented.  These 
costs  included  not  only  hardware,  but  any  associated 
software  packages  and/or  the  development  of  software. 

•  Allocation  of  Resources  -  Given  technological  alternatives 
and  the  costs  associated  with  each,  a  resource  allocation 
analysis  was  planned.  This  analysis  would  involve  treating 
each  functional  requirement  (individually  or  in  sets)  as 
the  key  variable.  For  each  functional  requirement,  several 
levels  of  fidelity  would  be  established  (e.g.,  high, 
medium,  low,  and  very  low).  For  each  fidelity  level,  a 
cost  and  benefit/  utility/desirability  value  would  be 
assigned.  The  cost  value  would  be  based  upon  the  techno¬ 
logical  alternatives  and  costs  resulting  from  the  previous 
analyses.  The  benefit/utility/  desirability  value  assigned 
to  each  fidelity  level  would  reflect  a  subjective  appraisal 
of  the  training  value  of  that  fidelity  level  in  terms  of 
such  factors  as  transferability  to  a  field  environment  and 
relevance  to  achieving  training  goals.  Once  each  of  these 
values  for  individual  sets  of  functional  requirements  had 
been  specified,  resource  allocation  analyses  would  be  per¬ 
formed.  These  analyses  could  be  keyed  to  any  variable 
contained  in  the  database,  e.g.,  benefit/utility/  desira¬ 
bility,  fidelity,  or  costs. 

•  Alternative  Configurations  -  The  resource  allocation 
analyses  would  have  resulted  in  identification  of  alterna¬ 
tive  SIKCAT  configurations.  These  alternatives  would  be 

described  in  terms  of  the  variables  considered  in  the 
resource  allocation  analyses,  e.g.,  level  of  fidelity, 
costs,  or  benefits. 

These  analyses  will  be  performed  in  the  near  future.  The  product 
of  these  analyses  will  be  the  identification  of  two  alternative  system 
configurations  and  associated  costs,  i.e.,  a  high  cost  and  a  low  cost 
configuration.  It  is  anticipated  that  the  high  cost  alternative  will  be 
capable  of  satisfying  all  the  functional  requirements  specified  in  this 


document.  Conversely,  it  is  realized  that  some  of  the  functional 
requirements  defined  may  not  be  satisfied  by  the.  low  cost  alternative. 

Identification  of  Functional  Requirements 


SIMCAT  must  satisfy  a  multitude  of  vastly  different  functional 
requirements.  To  define  these,  some  form  of  classification  is  required 
so  that  they  can  be  organized  and  comprehensible.  Such  a  classification 
evolved  during  the  development  of  the  functional  requirements.  Specifi¬ 
cally,  ten  categories  of  functional  requirements  were  classified  as 
follows: 

•  Initialization  -  These  functional  requirements  involve  the 
system  processes  necessary  to  begin  a  SIMCAT  simulation, 
e.g.,  identification  of  scenario  conditions  (such  as  TO&Es 
and  missions  for  each  of  the  opposing  forces)  ,  speech 
enrollments  (necessary  if  voice  recognition  is  involved), 
and  selection  of  terrain.  Since  initialization  functional 
requirements  are  dependent  upon  the  manner  in  which  the 
remaining  nine  categories  of  functional  requirements  are 
going  to  be  satisfied,  this  category  of  functional  require¬ 
ments  has  yet  to  be  developed.  Once  it  is  resolved  which 
functional  requirements  specified  in  this  document  are 
going  to  be  pursued  and  the  manner  in  which  each  is  going 
to  be  satisfied,  this  category  of  functional  requirements 
will  be  developed. 

•  Terrain  -  These  functional  requirements  involve  providing 
each  SIMCAT  position  (i.e.,  controller/trainer ,  trainee, 
and  OPFOR)  with  knowledge  about  the  terrain  in  which  he  is 
operating,  or,  in  the  case  of  the  controller/trainer ,  the 
terrain  within  which  both  the  OPFOR  and  friendly  forces  are 
operating.  These  functional  requirements  are  defined  in 
terms  of  terrain  characteristics,  traf f icability ,  and  the 
perception  requirements  for  each  SIMCAT  position. 

•  Movement  -  The  process  and  representation  requirements  for 
movement  are  defined  as  they  relate  to  the  object  that  is 
moving,  the  rate  of  movement,  the  control  of  movement,  and 
the  perception  of  movement. 

•  Dctection/Identif  i.cat  icn  -  This  category  of  functional 
requirements  concerns  the  relevant  objects,  events,  and 
conditions  of  the  simulation  environment  that  may  be 
detected  and  possibly  identified  by  each  participant  in  a 
SIMCAT  simulation. 

•  Engagement  -  The  purpose  of  the  functional  requirements  for 
engagement  is  to  resolve  all  encounters  between  the  mili¬ 
tary  weapon  systems  being  simulated  in  a  scenario.  An 
encounter,  in  this  context,  is  defined  as  the  firing  of  one 
or  more  OPFOR  or  friendly  forces  weapon  systems  and  the 
effect,  if  any,  on  the  engaged  targets. 


•  Indirect  Fire  -  Dedicated  indirect  fire  support  will  be 
provided  to  each  of  the  opposing  forces  in  all  SIMCAT 
scenarios.  To  satisfy  this  requirement,  SIMCAT  must  main¬ 
tain  a  record  of  all  indirect  fire  allocations,  provide  a 
means  for  requesting  indirect  fire.  Impact  indirect  fires, 
and  represent  the  effects  to  appropriate  SIMCAT  positions. 
The  representation  and  process  requirements  necessary  to 
satisfy  each  of  these  are  discussed  in  detail. 

•  Communication  -  The  communication  functional  requirements 
are  specified  in  terms  of  four  communication  networks 
(nets):  platoon,  company/team,  tank  intercom,  and  con¬ 
troller.  The  purpose  of  each  net  and  the  SIMCAT  positions 
Involved  in  each  net  are  defined. 

•  Resources  Audit  -  These  functional  requirements  dictate 
that  SIMCAT  maintain  an  audit  of  all  munitions  and  fuel 
expended  by  each  weapon  system  and  vehicle  simulated  in  a 
scenario.  Given  a  specified  allocation  of  fuel  or  muni¬ 
tions,  SIMCAT  must  audit  the  expenditures  of  these 
resources  as  they  occur  and  prevent  further  expenditures 
once  a  resource  has  been  exhausted. 

•  Time  -  These  functional  requirements  dictate  that  SIMCAT  be 
sensitive  to  and  represent  two  different  types  of  time: 
simulation  time  and  real  time.  Each  of  these  types  of  time 
will  be  discussed  and  information  on  the  functional  require¬ 
ments  regarding  simulation  time  will  follow. 

•  Post-Simulation  -  These  functional  requirements  specify  the 
SIMCAT  processes  necessary  to  support  controller/trainer 
responsibilities  associated  with  providing  feedback  to 
trainees.  Post -simulation  functional  requirements  are 
divided  into  three  categories:  visual  playback,  audio  or 
communication  playback,  and  hard  copy  outputs. 

Descriptions  of  the  Functional  Requirements 
for  SIMCAT 


The  following  pages  contain  separate  sections  for  nine  of  the  ten 

categories  of  functional  requirements  Identified  previously.1  Each 
section  varies  in  forir.at  because  the  nature  of  each  functional  require¬ 
ment  varies.  For  example,  some  functional  requirements  emphasize 
process  requirements  while  others  emphasize  representation  requirements. 
In  cases  where  the  rationale  for  a  functional  requirement  was  obvious. 


initialization,  omitted  here,  is  the  one  functional  requirement  that  is 
dependent  on  how  the  other  nine  functional  requirements  are  met. 
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Che  rationale  was  not  documented;  where  a  rationale  was  less  obvious,  an 
effort  was  made  to  document  it.  Where  appropriate,  tables  and  figures 
are  used  to  further  define  functional  requirements. 


Terrain 


The  functional  requirements  for  terrain  are  to  provide  the  trainees 
and  the  OPFOR  knowledge  of  the  terrain  in  which  they  are  operating,  and 
to  provide  the  controller/trainer  knowledge  of  the  terrain  in  which  both 
the  OPFOR  and  friendly  forces  (trainees)  are  operating.  Terrain  func¬ 
tional  requirements  are  discussed  below  in  terms  of  characteristics, 
traf f icability,  and  perception. 


Characteristics 


Terrain  characteristics  are  the  natural  and/or  man-made  objects 
found  in  the  tactical  scenarios  inherent  in  SIMCAT.  In  the  real  world, 
an  indefinite  number  or  type  of  terrain  characteristics  are  possible. 
SIMCAT  terrain  characteristics,  however,  are  restricted  to  representa¬ 
tions  of  the  following: 

•  Man-Made  Objects: 

-  Intact  bridge  (i.e.,  overpass) 

-  Blown  primary  road  bridge  over  a  stream 

-  Paved  secondary  road 

-  Major  road  (two  lane,  concrete) 

-  Underpass  (secondary  road  overpassing  a  major  road) 

-  Exposed  mines  across  a  major  roadway 

-  Hidden  minefields 

•  Vegetation  and  Water: 

-  Woods  (traversable  in  a  tank) 

-  Open,  traversable  grasslands 

-  Stream  with  depth  of  12  feet  or  more 

-  Sr.:.  11  pends 

•  Relief : 

-  Hills  with  elevations  ranging  from  100  feet  to  300  feet 

-  Tank  traversable  ridge 

-  Nontraversable  (for  tanks)  stream  bank 


Traf  f icabll ity 

Traff icability  is  the  effect  of  terrain  on  movement  rates  and  tra- 
versability  (e.g.  ,  tanks  can  traverse  open,  relatively  flat  grasslands, 
but  cannot  traverse  a  30  foot  high,  90°  bank).  Traff icability  func¬ 
tional  requirements  do  not  dictate  any  representation  requirements,  but 
dictate  several  modeling  requirements  (i.e.,  friendly  tanks  should  not 
be  permitted  to  move  at  their  maximum  rate  in  wooded  terrain) .  These 
modeling  requirements  are  specified  later  in  the  section  on  movement 
functional  requirements  for  SIMCAT. 


Perception 

Each  SIMCAT  position  requires  a  somewhat  different  perception  of 
terrain.  This  difference  in  perception  only  relates  to  the  area  or  size 
of  the  piece  (and,  consequently  the  scale)  of  the  terrain  which  is 
represented  to  each  position.  Specifically,  these  perception  require¬ 
ments  are  as  follows: 

•  Trainees  -  Each  trainee  should  have  represented  to  him  only 
the  terrain  which  is  within  his  line  of  sight  given  his 
location  relative  to  terrain  characteristics  (e.g.,  vege¬ 
tation  and  relief)  and  obscurants  (e.g.,  smoke).  Each 
trainee  should  be  provided  with  a  360°  perspective  of  the 
terrain  given  the  aforementioned  constraints.  Because  it 
is  impossible  for  two  tanks  to  occupy  the  same  space  simul¬ 
taneously,  this  requirement  dictates  that  each  trainee  be 
provided  a  somewhat  different  terrain  representation. 

Also,  since  each  trainee  will  have  the  ability  to  move  in 
any  direction  at  any  time,  each  of  these  terrain  represen¬ 
tations  will  change,  and  it  will  be  necessary  for  SIMCAT  to 
represent  each  tank  position  on  the  terrain. 

•  OPFOR  -  There  will  be  a  single  individual  controlling  all 
OPFOR  vehicles  and  weapon  systems.1  These  vehicles  will 
seldom,  if  ever,  be  in  close  proximity  to  one  another 
(correspondingly,  in  a  real  situation,  seldom  will  each 
vehicle  have  all  other  vehicles  in  visual  sight).  Instead, 
they  usually  will  be  dispersed.  Because  the  OPFOR  player 
must  be  aware  of  the  location  of  all  of  these  vehicles  at 
all  times,  and  because  they  are  likely  to  be  dispersed, 

a  large  area  of  terrain  (relative  to  what  is  to  be  repre¬ 
sented  to  each  trainee)  must  be  represented  to  the  OPFOR 
player.  As  in  the  case  of  the  trainee  position,  only  the 
terrain  which  is  within  the  line  of  sight  of  the  vehicles 
and  weapon  systems  he  is  controlling  should  be  represented 
to  the  OPFOR  player.  Once  line  of  sight  (360°  perspective) 


^here  will  be  a  maximum  of  ten  OPFOR  vehicles  and/or  weapon  systems  due 
to  cost  constraints. 
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for  each  OPFOR  vehicle  has  beer,  determined  by  SIKCAT,  a 
terrain  representation  for  each  vehicle  should  then  be 
presented  to  the  OPFOR  position. 

Controller /Trainer  -  The  terrain  represented  to  the 
controller/  trainer  will  encompass  an  area  even  larger  than 
that  presented  to  the  OPFOR  position.  This  is  necessary 
because  the  controller/  trainer  must  be  provided  with  a 
God's-eye  view  of  the  entire  area  occupied  by  both  friendly 
forces  and  OPFOR.  This  functional  requirement  should  not 
be  interpreted  to  mean  that  the  entire  offensive  zone  of 
operation  for  the  friendly  force  must  be  represented  to  the 
controller/  trainer  at  any  point.  This  will  seldom,  if 
ever,  be  necessary.  Instead,  three  possible  controller/ 
trainer  terrain  representations  are  envisioned: 

-  Initial  Defensive  Position  -  Once  a  defense  has  been 
established  (by  either  an  OPFOR  or  friendly  force),  the 
controller/trainer  must  be  provided  with  a  God's-eye  view 
of  the  defensive  zone.  This  zone  should  include  all  of 
the  terrain  within  line  of  sight  of  all  defensive  posi¬ 
tions  collectively.  At  this  point,  it  will  not  be 
necessary  to  represent  the  terrain  within  the  line  of 
sight  of  offensive  forces. 

-  Movement  Zone  -  Once  an  offense  force  has  crossed  its  LD 
(line  of  departure) ,  the  terrain  represented  to  the  con¬ 
troller/trainer  need  only  show  a  God's-eye  view  of  the 
offensive  movement  area.  This  terrain  representation 
should  be  a  composite  of  the  terrain  within  the  line  of 
sight  of  all  offensive  vehicles  collectively.  At  this 
point,  it  will  not  be  necessary  to  represent  the  terrain 
within  the  line  of  sight  of  defensive  vehicles. 

-  Offense/Defense  Merge  -  At  the  point  where  one  or  more 
offensive  vehicles  are  within  line  of  sight  of  one  or 
more  defensive  vehicles,  SIMCAT  should  automatically 
provide  the  controller/  trainer  with  a  composite  terrain 
representation  of  all  terrain  occupied  by  and  within  the 
line  of  sight  of  all  offensive  and  defensive  vehicles. 
This  terrain  representation  need  not  include  terrain  to 
the  rear  of  the  defense  nor  to  the  rear  of  the  last 
vehicle  of  the  offense. 

NOTE:  The  three  controller/trainer  terrain  representations 
should  involve  at  least  three  different  scale  terrain  rep¬ 
resentations.  The  approach  should  permit  the  controller/ 
trainer  to  switch  views  between  offense  and  defense  until 
detection  occurs.  At  this  point,  the  controller/trainer 
should  have  no  control  or  choice  of  what  is  represented. 
Upon  detection,  the  terrain  representation  should  include 
all  terrain  within  the  line  of  sight  of  all  vehicles 
(offense  and  defense)  involved  in  the  simulation.  This 
perspective  is  necessary  if  the  controller/trainer  is  to 
monitor  all  activities. 


Movement 


Determining  what  moves,  the  rate  at  which  something  moves,  the 
control  of  movement,  and  the  perception  of  movement  are  all  critical  to 
achieving  the  training  objectives  of  SIMCAT.  The  movement  functional 
requirements  vary,  depending  on  the  SIMCAT  position  being  addressed. 

•  Trainee  -  The  platoon  leader,  platoon  sergeant,  and  two 
tank  commanders  will  each  control  the  movement  of  his  own 
tank.  The  movement  functional  requirements  for  this  posi¬ 
tion  are  covered  in  the  following  subsections: 

-  Trainee  Tank  Movement 

-  Trainee  Tank  Engine  Control 

-  Trainee  Turret/Main  Gun  Movement 

•  OP FOR  -  One  person  will  control  the  movement  of  all  OPFOR 
elements  (i.e.,  tanks  or  other  vehicles  and  their  associa¬ 
ted  weapon  systems).  The  movement  functional  requirements 
for  this  position  are  covered  in  the  following  subsections: 

-  OPFOR  Vehicle  Movement 

-  OPFOR  T72  Tank  Turret  and  BMP  73mm  Gun/Sagger  Movement 

•  Controller/Trainer  -  A  single  individual  will  be  responsi¬ 
ble  for  controlling  the  entire  SIMCAT  simulation.  The 
control  is  limited  to  creating  the  initial  conditions, 
monitoring  the  actions  of  both  OPFOR  and  friendly  forces 
for  the  duration  of  the  simulation,  and  providing  feedback 
to  all  participants  both  during  and  after  the  simulation. 

With  respect  to  movement  functional  requirements  for 
SIMCAT,  it  is  the  monitoring  responsibilities  of  the  con¬ 
troller  that  are  of  most  concern.  The  movement  functional 
requirements  for  this  position  are  covered  in  the  following 
subsection: 

-  Controller/Trainer  Movement  Requirements 

Each  of  these  movement  functional  requirements,  with  the  exception 
of  trainee  tank  engine  control,  will  be  discussed  individually  in  terms 
of  direction,  rate,  control,  and  perception.  For  purposes  of  this  dis¬ 
cussion,  these  terms  are  defined  as  follows: 

•  Direction  -  The  line  or  course  (expressed  in  terms  of 
degrees)  on  which  a  simulated  vehicle  and  its  turret  (in 
the  case  of  a  trainee  only)  are  permitted  to  move. 

•  Rate  -  The  speed  at  which  a  simulated  vehicle  or  turret  is 
moving. 


•  Control  -  The  manner  in  which  both  the  direction  and  rate 
of  movement  of  the  simulated  vehicles  or  turrets  are  con¬ 
trolled.  Control  requirements  will  vary  depending  on  the 
S1MCAT  position  being  addressed. 

•  Perception  -  The  visual  image  of  movement  which  must  be 
portrayed  to  each  SIMCAT  position.  The  visual  image  move¬ 
ment  requirements  will  vary  depending  on  the  particular 
position. 


Trainee  Tank.  Movement 


A  trainee  will  be  responsible  for  controlling  the  movement  of  his 
tank  in  all  situations,  including  combat.  In  this  context,  movement 
includes  both  the  direction  in  which  a  tank  moves  and  its  rate  of  speed. 
It  is  imperative  that  SIMCAT  permit  the  trainee  to  control  the  movement 
of  his  tank.  Specifically,  this  requires  SIMCAT  to  satisfy  the  follow¬ 
ing  functional  requirements: 

Direction.  Each  trainee  must  be  capable  of  moving  his  tank  in  any 
direction  (i.e. ,  360°)  at  any  point  on  terrain  representation,  and  at 
any  time  during  simulation. 

Regarding  the  area  of  operation,  SIMCAT  must  restrict  movement  to 
the  platoon  zone  of  operation.  SIMCAT  should  automatically  prevent  a 
trainee  from  moving  outside  of  this  zone  by  automatically  generating  a 
message  from  the  company  team  leader  advising  the  trainee  of  his  error. 

Rate.  Maximum  rate  of  speed  for  Ml  Abrams  tanks  will  differ 
depending  on  the  following  terrain  characteristics  or  driving  condi¬ 
tions: 

Primary  and  Secondary  Roads:  40  MPH 

Open,  Traversable  Grasslands:  20  MPH 

Wooded  Areas:  10  MPH 

Any  Grade:  20  MPH 

Stream  Ford:  4  MPH 

Moving  in  Reverse:  10  MPH 

NOTE:  These  are  maximum  speeds  for  the  conditions  specified. 
Trainees  have  the  option  of  moving  at  slower  rates  (see  below) . 

Control.  Each  trainee  must  have  control  of  both  the  direction  and 
rate  at  which  his  tank  is  moving.  To  achieve  the  fidelity  necessary  to 
satisfy  training  requirements,  this  control  should  involve  tank 
commander-to-driver  voice  commands  as  follows: 

•  Controlling  Direction  -  Direction  of  tank  movement  must  be 
controlled  verbally  by  each  trainee  using  formal  driving 
commands.  These  commands  will  be  restricted  to  the  follow¬ 
ing: 
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-  "Driver  Move  Out"  (Tank  must  respond  by  moving  forward, 
i.e.,  the  direction  in  which  the  tank  is  pointed  at  the 
time  the  command  is  given). 

-  "Driver  Stop" 

-  "Driver  Turn  Left" 

-  "Driver  Turn  Right" 

-  "Driver  Guide  Left" 

-  "Driver  Guide  Right" 

-  "Driver  Steady  On" 

-  "Driver  Rear"  (Tank  must  respond  by  moving  in  reverse, 
i.e.,  the  opposite  direction  in  which  the  tank  is  pointed 
at  the  time  the  command  is  given) . 

-  "Driver  SAGGER,  SAGGER"  (Tank  will  continue  in  the 
direction  of  the  last  command,  but  must  begin  to  zig-zag. 
The  zig-zag  movement  pattern  must  continue  for  fifteen 
seconds  or  until  another  driving  command  is  issued, 
whichever  occurs  first). 

NOTE:  Given  a  movement  command,  the  tank  must  continue  to 
follow  that  command  until  another  command  is  Issued  or 
until  a  nontraversable  terrain  feature  is  encountered.  In 
other  words,  SIMCAT  will  assume  a  non intelligent  (i.e., 
non-decision-making)  driver.  Therefore,  a  tank  will  not 
stop  automatically  at  the  crest  of  a  hill;  it  will  stop 
only  when  the  TC  issues  a  stop  command  to  the  driver. 

•  Controlling  Rate  -  Following  a  direction  command,  rate  of 
movement  must  be  at  the  maximum  rate  of  movement  given 
terrain  characteristics  (see  previous  section  on  con¬ 
trolling  rate) .  However,  the  TC  must  be  able  to  decrease 
and  subsequently  increase  his  tank  movement  rate  at  any 
time.  Therefore,  to  control  the  rate  of  movement,  the 
following  TC-to-driver  voice  commands  and  subsequent  move¬ 
ment  rates  are  required; 

“  "Driv^r  Slower"  -  The  rate  of  movement  is  immediately 
decreased  by  50%.  This  command  can  be  issued  until  the 
tank  reaches  2  MPH,  at  which  time  the  system  will 
ignore  any  additional  "Driver  Slower"  commands.  For 
example,  if  a  tank  is  moving  at  40  KPH  and  the  TC 
issues  a  "Driver  Slower"  command,  movement  rate  is 
decreased  to  20  MPH.  If  at  this  point,  the  TC  issues 
another  "Driver  Slower"  command,  the  movement  rate  is 
decreased  to  10  MPH.  Should  another  "Driver  Slower" 
command  be  issued,  the  movement  rate  immediately 
decreases  to  5  MPH.  Should  the  TC  issue  another 
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"Driver  Slower"  command,  SIMCAT  would  decrease  the 
speed  to  2-1/2  MPH.  Any  additional  "Driver  Slower" 
commands  would  be  ignored  by  SIMCAT  because  the 
resulting  speed  would  be  less  than  the  2  MPH  minimum 
speed  allowed. 

-  "Driver  Faster"  -  Tank  movement  rate  doubles  until 
maximum  rate  of  movement  is  obtained.  Because  the  rate 
of  movement  will  always  be  the  maximum  rate  of  movement 
given  terrain  characteristics,  this  command  will  be 
effective  only  when  it  follows  one  or  more  "Driver 
Slower"  commands.  If  a  tank  is  moving  at  the  maximum 
rate  and  the  TC  commands  "Driver  Faster,"  the  SIMCAT 
response  should  be  "I  can't  go  any  faster!" 

NOTE:  If  at  any  point  a  tank  is  moving  at  less  than  maxi¬ 
mum  rate  and  a  "SAGGER,  SAGGER"  message  is  issued,  tank 
movement  rate  should  automatically  resume  maximum  movement 
rate  and  begin  a  zig-zag  pattern. 

Perception.  Each  trainee  must  always  be  aware  of  the  following 
regarding  movement  of  his  tank. 

•  Tank  Orientation  -  The  front  of  a  trainee's  vehicle  must 
always  be  indicated  in  some  manner.  This  is  necessary 
because  the  trainee  must  be  aware  of  the  orientation  of  his 
tank  before  he  can  determine  the  appropriate  direction 
command  to  be  given. 

•  Direction  of  Movement  -  Any  time  a  trainee's  tank  is 
moving,  the  trainee  must  be  made  aware  of  the  direction  of 
that  movement. 

•  Rate  of  Movement  -  Each  trainee  must  be  capable  of  discern¬ 
ing  the  movement  rate  of  his  tank.  To  accomplish  this,  the 
movement  rate  of  the  tank  symbologies  should  be  to  scale 
depending  on  the  terrain  representation.  Having  done  this, 
the  trainee  hopefully  should  be  able  to  distinguish  among 
varying  rates  of  movement  of  his  tank. 


Trainee  Tank  Engine  Control 

Trainees  will  be  controlling  simulations  of  Ml  Abrams  tanks.  Since 
these  tanks  have  a  rapid  fuel  consumption  rate,  a  trainee  may  choose  to 
turn  the  engine  off  when  his  tank  is  stationary  (e.g.,  when  defending  a 
battle  position).  When  the  engine  is  off,  power  for  the  tank's  systems 
(e.g.,  thermal  imagery  sight  (TIS)  ,  tank  turret  movement)  is  provided  by 
batteries.  Therefore,  SIMCAT  must  provide  each  trainee  the  capability 
to  control  the  running  of  his  tank's  engine.  This  dictates  the  follow¬ 
ing  tank  engine  control  functional  requirements. 

Control.  Each  trainee  position  must  be  provided  the  capability  to 
turn  the  tank  engine  to  "off"  and  "on."  Although  this  is  normally 


accomplished  via  commands  from  the  TC  to  the  driver,  this  level  of 
fidelity  is  not  required.  A  simple  "Engine  On"  and  "Engine  Off"  button 
would  suffice.  It  should  be  noted  that  when  an  engine  is  turned  to 
"off"  the  tank  should  not  respond  to  TC-to-driver  movement  commands. 

Perception.  SIMCAT  must  provide  a  constant  cue  to  the  trainee 
signifying  whether  or  not  the  engine  on  his  tank  is  running.  However, 
as  was  the  case  with  control,  fidelity  is  not  of  great  concern.  There¬ 
fore,  SIMCAT  need  not  necessarily  provide  a  constant  "engine  running" 
auditory  cue  (e.g.,  the  sound  of  an  engine  running  when  the  engine  is 
running)  nor  constant  "silence"  when  the  engine  is  not  running.  An 
acceptable  alternative  might  be  to  have  the  "Engine  On"  and  "Engine  Off" 
buttons  light  up  when  one  or  the  other  is  in  effect. 


Trainee  Turret/Main  Gun  Movement 

The  position  of  the  turret  (i.e.,  the  orientation  of  the  main  gun) 
is  critical  to  combat  effectiveness  of  a  tank.  Since  main  gun  orienta¬ 
tion  is  the  responsibility  of  the  tank  commander,  it  is  imperative  that 
SIMCAT  attend  to  the  following  functions  associated  with  turret/main  gun 
movement : 

Direction.  At  any  point,  the  trainee  must  be  capable  of  position¬ 
ing  the  turret/  main  gun  in  any  direction  (i.e.,  360°).  He  must  be  able 
to  do  this  whether  the  tank  is  stationary  or  moving. 

Rate.  Turret/main  gun  movement  rate  is  not  of  great  concern. 
However,  it  should  neither  require  a  great  deal  of  time  nor  occur  at 
such  a  rapid  rate  that  it  is  difficult  to  control. 

Control.  The  mechanism  or  procedure  for  positioning  the  turret/ 
main  gun  need  not  be  high  fidelity.  SIMCAT  artifacts  (e.g.,  joystick, 
function  keys)  are  acceptable. 

Perception.  Each  trainee  must  always  be  aware  of  the  position  of 
the  turret  on  his  tank.  Again,  fidelity  is  not  of  concern;  some  form  of 
symbology  is  acceptable. 


OPFOR  Vehicle  Movement 

Movement  of  all  of  the  vehicles  and  weapon  systems  under  his  con¬ 
trol  is  essential  to  the  OPFOR  position.  S1MC.V,  therefore,  must 
provide  the  OPFOR  position  the  capability  to  novo  his  vehicles  both 
individually  and  together  as  a  group.  This  would  dictate  the  following 
OPFOR  vehicle  movement  functional  requirements: 

Direction.  At  any  point  on  terrain  representation,  and  at  any  time 
during  simulation,  the  OPFOR  position  must  be  capable  of  moving  any  of 
the  vehicle  and/or  weapon  systems  he  controls  in  any  direction  (i.e., 
360°).  He  must  be  permitted  to  move  each  of  his  vehicles  individually 
as  well  as  in  unison.  The  latter  requirement  is  necessary  in  situations 
where  several  of  his  vehicles  are  in  contact  and  the  time  required  to 
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move  each  vehicle  individually  would  be  prohibitive  (e.g.,  would  result 
in  exposure  of  his  vehicles  to  enemy  fire  for  an  unrealistic  period  of 
time) . 


Rate.  Rates  of  movement  would  be  identical  to  those  specified  for 
friendly  force  tanks.  Under  all  conditions,  OPFOR  vehicles  will  move  at 
maximum  rates  given  the  constraints  imposed  by  terrain  features, 
obscurants,  and  illumination. 


I 

\ 


\ 
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Control.  Given  that  the  OPFOR  position  must  have  the  ability  to 
control  up  to  ten  vehicles,  fidelity  in  terms  of  TC-to-driver  commands 
is  not  possible.  Nor  would  it  be  feasible  to  provide  joysticks  with 
which  the  OPFOR  player  would  control  the  movement  of  the  vehicles  indi¬ 
vidually  (because  of  the  time  that  would  be  necessary  to  move  each 
vehicle  individually).  Therefore,  the  OPFOR  position  must  have  the 
capability  to  quickly  identify  the  vehicle  he  wishes  to  move  and  the 
location  to  which  he  wishes  to  move  it.  SIMCAT  would  then  initiate  the 
movement,  control  its  movement  rate,  and  automatically  stop  the  vehicle 
when  it  reached  the  point  designated  by  the  OPFOR  position.  The  OPFOR 
position  should  be  permitted  to  designate  movement  of  each  vehicle 
immediately  following  each  movement  command.  This  would  necessitate 
that  SIMCAT  control  the  movement  of  several  OPFOR  vehicles  simultane¬ 
ously.  Aggregate  control  of  three,  possibly  more,  OPFOR  vehicles  (BMPs 
and/or  T72s)  should  be  considered. 

Perception.  The  OPFOR  position  must  be  cognizant  of  the  location 
and  movement  of  each  of  the  vehicles  under  his  control  at  all  times. 

Line  of  sight  or  intervisibility  among  OPFOR  vehicles  is  not  of  concern. 


OPFOR  T72  Tank  Turret  and  BMP  73mm  Gun/Sagger  Movement 

As  was  the  case  for  trainees,  the  positioning  or  orientation  of 
OPFOR  tank  main  guns  and  BMP  73mm  gun/SAGGERs  are  critical  factors  which 
must  be  considered  in  SIMCAT.  These  considerations  should  address  direc¬ 
tion,  rate,  control,  and  perception. 

Direction.  At  any  point,  the  turret  on  each  OPFOR  tank  and  the  gun 
or  SAGGER  on  each  BMP  must  be  capable  of  being  oriented  in  any  direction 
(i.e.,  360°).  The  orientation  of  each  turret  and  gun  or  SAGGER  must  be 
capable  of  being  changed  at  any  time  whether  the  weapon  system  platforms 
(i.e.,  a  tank  for  an  OPFOR  main  gun  and  BMP  for  SAGGERs  or  73mm  gun)  are 
moving  or  not. 

Rate.  The  rate  of  orienting  or  moving  an  OI'FO!  tank  turret  and  BMP 
73mm  gun  or  SAGGER  is  irrelevant  since  SIMCAT  will  orient  them  automat¬ 
ically. 

Control .  Manual  control  of  OPFOR  tank  turrets  and  BMP  73mm  gun  or 
SAGGER  orientations  by  the  OPFOR  position  is  neither  necessary  nor 
desirable.  SIMCAT  should  automatically  orient  these  weapon  systems  in 
tactically  appropriate  positions.  In  other  words,  SIMCAT  should  assume 
that  OPFOR  tank  main  guns  and  BMP  73mm  guns  or  SAGGERs  are  properly 
oriented  at  all  times. 
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Perception.  If  it  is  assumed  that  all  OPFOR  tank  main  guns  and  BMP 
weapon  systems  are  properly  oriented  at  all  times,  there  is  no  need  to 
cue  the  OPFOR  player  of  these  orientations  either  symbolically  or  by  any 
other  means. 


To  assess  tactical  situations  and  provide  proper  feedback  to 
trainees,  the  controller/trainer  must  always  be  aware  of  what  is  moving, 
at  what  speed  things  are  moving,  and  the  orientation  of  friendly  tank 
main  guns.  This  necessitates  that  SIMCAT  satisfy  the  following  func¬ 
tional  requirements: 

Direction.  The  controller/trainer  must  be  aware  at  all  times  of 
the  direction  of  movement  of  all  vehicles  (friendly  and  OPFOR)  in  the 
simulation.  In  addition,  the  controller/trainer  must  always  be  aware  of 
the  direction/  orientation  of  the  main  guns  on  friendly  force  tanks. 

Rate.  The  controller/trainer  must  be  aware  of  the  movement  rate  of 
each  vehicle  in  the  simulation  (see  section  on  perception,  below). 

Control.  The  controller/trainer  need  not  have  any  control  of  the 
direction  of  movement  or  movement  rate  of  either  OPFOR  or  friendly 
forces,  nor  of  the  orientation  of  the  main  guns  on  friendly  force  tanks. 


Perception 


The  controller/trainer  must  be  aware  of  the  following  at  all  times: 


•  Vehicle  Orientation  -  The  front  of  all  friendly  and  OPFOR 
vehicles  must  be  obvious  to  the  controller/trainer. 


•  Friendly  Force  Turret/Main  Gun  Orientation  -  The  position 
of  the  main  guns  on  all  friendly  force  tanks  must  be 
obvious  to  the  controller/trainer.  This  need  not  be  accom¬ 
plished  for  OPFOR  tank  main  guns  or  other  OPFOR  weapon 
systems  which  are  always  assumed  to  be  properly  oriented. 

•  Movement  -  The  direction  in  which  any  simulation  vehicle 
(i.e.^  friendly  tank  or  OPFOR  vehicle)  is  moving  must  be 
portrayed  to  the  controller/trainer. 


•  Movement  Rate  -  The  movement  rate  of  any  simulation  vehicle 
must  be  discernable  to  the  controller/  trainer.  This  does 
not  necessarily  dictate  that  all  movement  must  be  depicted 
to  scale  nor  depicted  in  continuous  motion.  For  example,  a 
symbol  could  move  in  1/4-inch  Increments  as  opposed  to 
moving  continuously  at  an  extremely  slow,  possibly  nonde- 
tectable,  rate.  However,  the  controller/trainer  should  be 
able  to  distinguish  rapid  from  slow  movement  rates. 
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Detect ion /Identification 


These  functional  requirements  concern  the  relevant  objects,  events, 
and  conditions  of  the  simulation  environment  which  may  be  detected  and 
subsequently  identified  by  each  participant  in  a  SIMCAT  simulation. 

These  functional  requirements  not  only  concern  what  can  be  seen  and 
heard,  but  also  address  the  manner  in  the  stimuli  are  to  be  represented 
to  the  SIMCAT  positions.  In  general,  these  functional  requirements  must 
consider  the  detection  of  the  following: 

•  tanks  (Mis,  T72s) 

•  BMPs 

•  instantaneous  events  (weapons  signatures,  other 
noises  and  flashes) 

•  transient  conditions  (smoke,  dust,  engine  noise) 

These  functional  requirements  must  also  address  how  to  determine  when 
detection  has  been  lost  by  each  SIMCAT  position. 

It  should  be  noted  that  detection,  in  this  context,  is  not 
restricted  to  detecting  only  opponent  forces  (i.e.,  OPFOR  detecting 
friendly  forces  and  friendly  forces  detecting  OPFOR  forces) .  In  this 
case,  detection  means  that  friendly  forces  must  have  the  ability  to 
detect  other  tanks  in  their  platoon  that  are  within  their  field  of 
vision;  and  in  the  case  of  the  OPFOR,  that  all  OPFOR  vehicles  must  be 
represented  to  the  OPFOR  position  at  all  times  regardless  of  line  of 
sight  restrictions  between  OPFOR  vehicles.  However,  the  OPFOR  ability 
to  detect  friendly  forces  must  be  restricted  by  line  of  sight  and  other 
considerations. 

The  detection/identification  functional  requirements  for  SIMCAT  are 
best  defined  in  terms  of  visual  detection,  visual  identification,  audi¬ 
tory  detection/location,  and  representation  requirements. 


Visual  Detection 


To  determine  whether  an  OPFOR  or  friendly  force  vehicle  detects 
something  visually,  two  questions  must  be  answered — "Can  it  be 
detected?"  and  "Do  they  see  it?"  To  answer  the  first  question,  SIMCAT 
must  determine  whether  or  not  line  of  sight  exists.  Terrain  character¬ 
istics1  (i.e.,  man-made  objects,  vegetation  and  water,  and  relief) 
located  between  the  friendly  or  OPFOR  simulation  vehicle  and  the  poten¬ 
tially  detectable  object,  event,  or  condition  must  be  considered  in 


terrain  characteristics  are  addressed  in  detail  in  SIMCAT  Terrain 
Functional  Requirements. 


determining  line  of  sight.  If  line  of  sight  does  exist,  the  range 
(i.e.,  distance  between  possible  detector  and  detectable  object)  must  be 
considered  to  answer  the  second  question  ("Do  they  see  it?") .  Many 
variables  must  be  considered  to  determine  the  effect  of  range  on  detec¬ 
tion.  These  would  include  the  size  and  disposition  (i.e. ,  stationary  or 
moving)  of  the  detectable  object  and  its  persistence  (e.g.,  solid 
object,  flash,  smoke),  all  of  which  are  mediated  by  the  possible  use  of 
sighting  devices.  With  respect  to  sighting  devices,  S1MCAT  must  always 
assume  that  friendly  forces  have  available  to  them  both  binoculars  and 
thermal  imagery  sights  (TIS) .  It  should  also  be  assumed  that  OPFOR  will 
have  binoculars  (but  not  TIS) .  As  a  result,  the  magnification  capabil¬ 
ity  of  both  binoculars  and  TIS  must  be  considered  at  ranges  which 
normally  would  eliminate  any  possibility  of  detection  by  the  naked  eye. 
Where  smoke  exists,  SIMCAT  must  always  assume  that  friendly  forces  will 
use  their  TIS  to  permit  them  to  see  through  it. 


Visual  Identification 

Once  the  system  has  considered  line  of  sight  and  range  and  has 
determined  that  an  object  can  be  detected,  an  additional  question  must 
then  be  asked — "What  does  he  see?"  Detection  does  not  necessarily  mean 
absolute,  100  percent  identification.  When  a  distant  object  is  detect¬ 
able  from  a  SIMCAT  vehicle,  the  degree  to  which  it  can  be  identified 
must  then  be  determined. 

Three  variables  can  affect  the  degree  to  which  a  detected  object 
can  be  identified  and  should  be  considered  by  SIMCAT.  The  first  of 
these  is  range.  For  example,  the  turret  of  a  tank  Is  far  easier  to 
identify  at  a  range  of  300  meters  (with  or  without  visual  aids  such  as 
binoculars)  than  it  would  be  at  1100  meters.  The  second  variable  is  the 
distortion  associated  with  the  use  of  a  Thermal  Imagery  Sight  and  its 
impact  on  the  probability  of  identifying  a  detected  object.  The  third 
variable  is  the  presence  of  obscurants  such  as  dissipating  smoke.  A 
detected  object  seen  through  a  dissipating  smoke  screen  is  likely  to  be 
more  difficult  to  identify. 


Auditory  detection  requires  that  the  sound  source  be  within  range 
of  a  possible  detector.  Range  or  distance  from  the  possible  detector  is 

not  the  only  variable  to  be  considered,  however.  The  noise  level  of  the 
virement  within  which  the  possible  detector  exists  (e.g..  a  tank  with 
engine  running)  must  be  considered  as  well  as  the  source  sound  level. 

The  computation  used  to  determine  the  requirement  to  represent  an  audi¬ 
tory  cue  should  also  consider  most  of  the  variables  previously  addressed 
regarding  line  of  sight  (e.g.,  terrain  characteristics)  all  of  which 
could  affect  noise  detection. 


Given  that  SIMCAT  has  determined  that  the  occupants  of  one  or  more 
SIMCAT  vehicles  (OPFOR  and/or  friendly)  have  visually  detected  something 
(e.g.,  vehicle  or  weapon  signature)  or  are  to  be  provided  with  an  audi¬ 
tory  cue,  SIMCAT  must  represent  this  cue  in  some  way  to  the  appropriate 
vehicle(s).  Specifically,  these  cue  representation  requirements  are  as 
follows: 

•  Auditory  -  Both  the  type  of  noise  (e.g.,  running  engine, 
explosion)  and  approximate  location  of  the  noise  source 
must  be  represented.  The  location  should  be  approximate 
and  need  not  be  entirely  accurate  because  it  is  extremely 
difficult  to  determine  the  exact  direction  and  range  of  a 
noise  source.  Equally  important  to  representing  the 
presence  of  an  auditory  cue  is  cueing  the  SIMCAT  partici¬ 
pant  when  the  noise  has  ceased. 

•  Location  of  Detected  Object.  Event  or  Condition  -  This 
representation  requirement  is  twofold.  First,  SIMCAT  must 
designate  to  the  detector  the  location  of  the  object,  event 
or  condition.  Second,  the  system  must  represent  the 
object,  event,  or  condition  itself  in  a  manner  which  per¬ 
mits  the  detector  to  distinguish  it  to  some  degree. 


•  Identification  of  Object.  Event  or  Condition  -  SIMCAT  must 
do  this  to  some  variable  level  of  accuracy.  For  example, 

SIMCAT  will  be  required,  no  doubt,  to  represent  a  T72  tank 
in  several  different  ways  depending  upon  conditions  (e.g., 
range,  presence  of  obscurants,  use  of  TIS) .  A  fully 
exposed  T72  seen  from  the  side  at  a  range  of  300  meters 
through  binoculars  would  be  represented  in  an  entirely 
different  manner  than  a  T72  detected  at  2000  meters  in 
defilade  through  a  TIS.  In  the  former  condition,  the  T72 
would  probably  be  identifiable  as  a  T72  tank.  In  the 
latter  condition,  it  would  probably  be  identifiable  as 
"some  type  of  vehicle." 

•  Loss  of  Detection  -  SIMCAT  must  also  provide  some  form  of 
notification  that  detection  of  an  object  has  been  lost  or 
degraded.  Examples  of  degraded  detection  would  be  a  tank 
moving  at  a  rapid  rate  away  from  the  detector,  or  a  dissi¬ 
pating  smokescreen  or  weapon's  signature. 

All  of  the  cue  representation  requirements  listed  above  are  equally 
applicable  to  all  SIMCAT  positions  (i.e.,  trainees,  OPFOR,  and  con¬ 
troller/trainer).  However,  the  OPFOR  and  controller/trainer  SIMCAT 
positions  have  additional  cue  representation  requirements  as  a  result  of 
the  God's  eye  perspective  to  be  provided  each  of  these  positions. 

Specifically,  SIMCAT  must  not  only  provide  the  controller/trainer 
and  OPFOR  positions  with  detection/identification  cues,  it  must  also 
designate  which  SIMCAT  vehicle(s)  is  doing  the  detection.  For  example, 


the  single  individual  occupying  the  OPFOR  position  will  constantly  be 
provided  with  representations  of  all  OPFOR  vehicles  and  weapon  systems 
involved  in  the  scenario  regardless  of  dispersion  and  intervisibility. 
Should  SIMCAT  determine  that  one  of  these  vehicles  (there  could  be  as 
many  as  ten)  detects  an  object,  event,  or  condition  and  the  other 
vehicles  do  not,  a  problem  arises.  SIMCAT  must  represent  the  cue  in 
some  manner  to  the  OPFOR  position.  However,  before  the  OPFOR  position 
can  take  any  action  (e.g.,  engage  the  object,  take  evasive  action),  he 
must  be  made  aware  of  the  specific  vehicles  that  have  detected  the 
object.  Therefore,  this  detection/detector  relationship  and  represen¬ 
tation  requirement  becomes  critical. 

A  somewhat  similar  detection/detector  relationship  problem  arises 
in  the  controller/trainer  position.  If  the  controller/trainer  is  to 
provide  complete  and  accurate  feedback,  he  must  know  who  sees  and/or 
hears  whatever  is  detected,  as  well  as  when  the  detection  occurs.  As  a 
result,  the  detection/  detector  relationship  representation  must  be 
provided  to  the  controller/  trainer  for  both  the  OPFOR  and  friendly 
forces. 

Should  detection  from  an  OPFOR  vehicle  and/or  friendly  tank  be 
distorted  as  a  result  of  TIS  usage,  range,  and/or  the  presence  of  smoke, 
the  controller/trainer  representations  must  reflect  these  conditions. 


Engagement 


The  purpose  of  the  engagement  functional  requirements  for  SIMCAT  is 
to  resolve  all  encounters  between  the  military  vehicles  being  simulated 
in  a  scenario.  An  encounter,  in  this  context,  is  defined  as  the  firing 
of  one  or  more  OPFOR  or  friendly  force  weapon  systems.  Engagement  func¬ 
tional  requirements  involve  five  basic  requirements.  First,  SIMCAT 
should  model  the  operational  characteristics  associated  with  the  use  of 
various  weapon  systems,  including  variables  such  as  reload  times. 

Second,  SIMCAT  should  model  the  potential  effects  resulting  from  the  use 
of  weapon  systems  including  vehicle/  equipment/weapon  system  damage  and 
destruction,  personnel  kills,  and  suppression.  Third,  the  effects,  if 
any,  of  a  successful  engagement  by  a  weapon  system  (i.e.,  a  hit)  must  be 
represented  to  the  different  SIMCAT  positions  (i.e.,  controller /trainer , 
OPFOR,  and  trainees)  with  varying  degrees  of  specificity.  For  example, 
if  one  tank  engages  another  and  obtains  a  direct  hit,  the  tank  that  was 
hit  certainly  would  know  that  his  turret  is  no  longer  functioning,  while 
the  tank  firing  the  round  would  not  necessarily  be  aware  of  this  fact. 
Fourth,  the  detectable  events  and  conditions  created  as  a  result  of  a 
weapon  system  firing  (i.e.,  weapon  signature,  impact  of  munitions)  must 
be  represented  to  the  appropriate  SIMCAT  positions.  Fifth,  SIMCAT  must 
maintain  an  audit  of  the  amount  of  munitions  expended  by  each  weapon 
system. 

SIMCAT* s  engagement  functional  requirements  can  be  specified  best 
by  addressing  each  of  the  following: 


•  Weapon  Systems  Involved 

•  Control  of  Ml  Abrams  Weapon  Systems 

•  Control  of  OPFOR  Weapon  Systems 

•  Weapon  Effects  Modeling 

•  Representation  Requirements 


One  of  the  most  critical  factors  or  variables  that  must  be  con¬ 
sidered  in  the  development  of  engagement  modeling  and  representation 
processes  is  the  weapon  system  involved.  In  the  initial  version  of 
SIMCAT,  there  will  only  be  a  few  weapon  systems  although  the  number  can 
easily  be  increased  at  a  future  date.  The  weapon  systems  and  their 
associated  basic  loads  are  specified  in  Table  1. 


Table  1 


SIMCAT  Weapon  Systems  and  Their  Associated  Basic  Loads 


WEAPON  SYSTEM  BASIC  LOAD 

Friendly  Forces  (i.e. ,  Ml  Tank): 

Coax  10,000  rounds  (every  5th  round  a  tracer) 

Main  G  33  rounds  (APFSDS  (735  series  or  up) 

22  rounds  HEAT 

Mines  4  A.T.  Mines 

OPFOR  (i.e.,  T72  and  BMP): 

T72  Main  Gun  40  rounds  HAVAPFSDS 

SAGGER  (mounted  on  BMP)  4  rounds 

73mm  Gun  (on  BMP)  40  rounds  (assume  all  are  HEAT) 


Mines 


Type  and  number  to  be  determined 


The  basic  loads  specified  in  Table  1  for  each  weapon  system 
represent  the  maximum  number  and  type  of  rounds  that  should  be  allocated 
for  that  weapon  system.  While  the  controller/trainer  should  not  be  able 
to  increase  these  numbers  in  any  scenario,  he  should  be  permitted  to 
decrease  them  if  he  desires  to  do  so. 


Control  of  Ml  Abrams  Weapon  Systems 


Each  SIMCAT  trainee  position  will  have  total  control  of  the  tank 
weapon  systems  at  that  position.  An  Ml  tank  has  four  weapon  systems 
aboard:  the  tank  main  gun,  a  coax  machinegun,  a  .50  caliber  machinegun, 
and  the  loader's  7.62mm  machinegun.  Only  the  tank  main  gun  and  the  coax 
machinegun  will  be  simulated  in  SIMCAT.  On  an  Ml  tank,  the  main  gun  and 
coax  can  be  fired  by  either  the  gunner  or  the  TC.  In  SIMCAT,  however, 
only  the  gunner1  will  be  permitted  to  fire  these  weapons. 


Given  that  only  the  tank  commander  will  be  present  during  a 
simulation,  SIMCAT  has  certain  Ml  weapon  system  control  functional 
requirements  it  must  satisfy.  These  requirements  can  be  defined  most 
easily  by  addressing  the  tank  main  gun  and  coax  collectively. 


•  Control  of  Tank  Main  Gun  and  Coax  -  Both  the  tank  main  gun 
and  coax  on  an  Ml  tank  can  be  controlled  by  either  the 
gunner  or  TC.  As  stated  previously,  in  SIMCAT,  the  TC  will 
not  be  permitted  to  actually  fire  either  of  these  weapons 
systems.  Instead,  the  TC  will  issue  fire  commands  to  the 
gunner  and  loader  in  the  same  manner  that  he  would  in  a 
real  tank.  In  SIMCAT,  these  commands  could  be  handled  in  a 
number  of  ways  (e.g.,  voice  synthesis/  recognition,  func¬ 
tion  keys,  screen  menus  with  keyboard  inputs,  textual 
input/output) .  It  is  highly  desirable  that  voice 
synthesis/  recognition  technologies  be  employed.  This  is 
the  only  alternative  that  will  provide  the  fidelity 
necessary  to  achieve  training  objectives.  For  the 
remaining  discussion  of  this  function  requirement,  it  is 
irrelevant  which  technology  will  eventually  be  used.  If 
voice  technology  is  used,  it  can  be  assumed  that  sending 
messages  from  the  gunner  to  the  TC  will  involve  voice 
synthesis.  If  voice  technology  is  not  used,  it  can  be 
assumed  that  a  textual  output  on  a  CRT  will  be  used. 

Once  a  trainee  has  identified  a  target  he  wishes  to  engage 
with  either  the  coax  or  the  main  gun,  SIMCAT  must  first 
allow  the  trainee  to  traverse  the  turret  so  that  the  main 
gun  and  coax  are  pointed  in  the  general  direction  of  the 
target  (this  functional  requirement  is  addressed  in  detail 
in  the  discussion  of  SIMCAT' s  movement  functional  require¬ 
ments).  Once  this  has  been  accomplished,  SIMCAT  must 


^n  actuality,  the  gunner  position  will  be  simulated. 
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accommodate  (through  voice  recognition/  synthesis,  function 
kcys/textual  output,  etc.)  a  series  of  trainee  gunner  and 
loader  verbalizations.  The  sequence  of  commands  and 
verbalizations  and  the  functional  requirements  related  to 
them  are  as  follows: 

-  TC  Provides  Alert  to  Gunner  -  The  TC  will  call  out 
"Gunner!"  over  the  tank  intercom.  This  alert  normally  is 
provided  at  the  same  time  the  TC  is  traversing  the  turret 
in  the  general  direction  of  the  target.  The  purpose  of 
the  command  is  to  alert  the  gunner  that  the  TC  wants  him 
to  engage  a  target. 

-  TC  Identifies  Weapon  System  to  Engage  -  The  gunner, 
having  been  alerted  that  he  should  prepare  to  engage  a 
target,  now  must  be  told  which  weapon  system  (coax  or 
main  gun)  he  should  use  to  engage  the  target.  If  the  TC 
wants  the  gunner  to  engage  the  target  with  the  coax,  the 
TC's  next  command  over  the  tank  intercom  will  be  simply, 
"Coax!"  If  the  TC  wants  the  gunner  to  engage  the  target 
with  the  tank  main  gun,  the  TC's  next  command  over  the 
tank  intercom  will  be  either  "HEAT!"  or  "SABOT!",  speci¬ 
fying  which  of  the  two  types  of  tank  main  gun  rounds 
should  be  used.  This  command  will  actually  be  directed 
at  the  loader  who  will  load  the  round  specified. 

-  TC  Describes  Target  -  The  TC  will  then  describe  over  the 
intercom  the  target  to  be  engaged  (e.g.,  "Tank,"  "BMP"). 
SIMCAT  need  not  recognize  the  target  description  given  by 
the  TC  because  SIMCAT  will  be  controlling  the  gunner 
actions  and  will  be  aware  of  what  the  TC  has  detected. 
Therefore,  SIMCAT  can  ignore  this  portion  of  the  firing 
command. 


Loader  Announces  Message  -  Next,  the  loader  will  announce 
"Up!"  when  the  round  has  been  loaded.  SIMCAT  must  pro¬ 
vide  this  message  to  the  trainee  (over  the  tank  intercom, 
if  voice  synthesis  is  used) . 


Gunner  Announces  Message  -  SIMCAT  must  then  provide  the 
message  "Identified"  from  the  gunner  to  the  TC  (over  the 
voice  intercom  if  voice  synthesis  is  used). 


IC  Gives  Lire  Comr.-.-nd  -  Once  the  loader  lias  sc  id  "Up 
the  gunner  has  said  "identified,"  the  TC  will  give  the 
command  "Fire!".  At  this  point,  SIMCAT  should  cause  the 
tank  main  gun  or  coax  (depending  on  the  weapon  system 
specified  by  the  TC  earlier)  to  fire. 
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Gunner  Gives  Fire  Response  to  TC  -  If  the  tank  main  gun 
is  to  be  fired,  SIMCAT  must  output  the  message  "On  the 
Way!"  from  the  gunner  to  the  TC  over  the  tank  intercom. 
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-  Subsequent  Firing  Activity  -  At  this  point  during  main 
gun  firing,  several  activities  are  possible,  depending 
upon  certain  conditions  (e.g.,  whether  or  not  the  round 
hits  its  target,  whether  or  not  the  gunner  can  see  the 
round  impacting  down  range) .  In  SIMCAT,  the  conditions 
subsequent  to  main  gun  firing  will  be  held  constant. 
Specifically,  it  will  always  be  assumed  that  the  gunner 
can  see  the  target  and,  when  a  HEAT  round  has  missed, 
that  the  gunner  will  always  be  able  to  determine  if  the 
round  was  short,  long,  or  to  the  left  or  right  of  the 
target  being  engaged,  but  not  when  a  SABOT  round  has 
missed  since  it  cannot  be  detected.  Given  that  these 
conditions  will  be  held  constant,  there  no  longer  will  be 
any  requirement  for  the  TC  to  communicate  with  the  gunner 
or  loader.  However,  the  gunner  will  have  to  provide 
feedback  to  the  TC.  This  feedback  will  vary  depending  on 
whether  or  not  the  target  was  hit,  as  in  the  following 
situations: 

•  If  the  target  was  hit,  the  gunner  (i.e.,  SIMCAT)  will 
tell  the  TC  "Target"  over  the  tank  intercom. 

•  If  the  target  was  missed,  the  gunner  (i.e.,  SIMCAT) 
will  tell  the  TC  "Re-engaging."  Given  that  the  gunner 
will  always  be  presumed  to  have  seen  the  target  and  the 
relationship  of  the  target  to  the  area  where  his  missed 
round  impacted,  the  gunner  will  fire  automatically  at 
the  target  once  again.  This  will  continue  until  the 
target  is  hit. 

NOTE:  If  a  target  disappears  (e.g.,  moves  out  of  sight), 
SIMCAT  should  automatically  cease  all  gunner  activities.  In 
addition,  the  TC  should  be  able  to  issue  a  "Cease  Fire" 
command  to  the  gunner  to  signify  that  he  wishes  the  gunner  to 
stop  firing. 


Control  of  OPFOR  Weapon  Systems 

The  individual  occupying  the  SIMCAT  OPFOR  position  will  be  provided 
at  all  times  with  representations  of  the  location  and  movement  of  all 
OPFOR  vehicles  as  specified  in  the  sections  on  SIMCAT  movement,  terrain, 
and  detection/  identification  functional  requirements.  It  is  this  con¬ 
dition  that  dictates  most  of  the  functional  requirements  associated  with 
the  control  of  OPFOR  weapon  systems  (which  differ  considerably  from  the 
functional  requirements  for  friendly  force,  i.e.,  Ml  Abrams  weapon 
system  control)  .  Specifically,  SIMCAT  must  provide  the  OPFOR  position 
the  capability  of  either  manually  controlling  the  weapon  systems  of 
OPFOR  vehicles  or  allowing  SIMCAT  to  control  OPFOR  weapon  system  firings 
automatically.  Manual  weapon  system  control  would  necessitate  the 
following  functional  requirements. 
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•  Identification  of  Weapon  Platform  To  Pse  -  Given  that  the 
OPFOR  position  will  have  represented  to  him,  at  all  times, 
the  location  of  all  his  weapon  system  platforms  (i.e.,  BMPs 
and  T72s)  as  well  as  anything  detected  (i.e.,  potential 
targets)  by  each  platform,  he  must  have  the  capability  to 
identify  which  weapon  platform  he  wishes  to  fire. 

•  Identification  of  Weapon  System  -  As  stated  previously,  two 
weapon  platforms  will  be  involved  in  the  OPFOR  forces— T72 
tanks  and  BMPs.  Only  one  T72  tank  weapon  system  will  be 
simulated — its  main  gun.  Therefore,  when  the  OPFOR  posi¬ 
tion  selects  a  T72  as  the  weapon  platform  he  wishes  to 
fire,  it  will  always  be  its  main  gun  that  fires.  However, 
should  the  OPFOR  position  select  a  BMP  as  the  weapon  plat¬ 
form  to  engage  a  target,  there  are  two  weapon  systems  that 
could  fire — a  73mm  gun  and  a  SAGGER.  Therefore,  whenever 
the  OPFOR  position  identifies  a  BMP  as  the  weapon  platform 
to  engage,  SIMCAT  must  also  permit  him  to  select  which 
weapon  system(s)  on  board  the  BMP  he  wishes  to  fire — the 
73mm  gun,  the  SAGGER,  or  both. 

•  Target  Identification  -  At  any  time,  a  single  OPFOR  vehicle 
(i.e.,  T72  or  BMP)  may  have  simultaneous,  multiple  target 
opportunities.  In  addition,  since  all  OPFOR  vehicles  will 
be  represented  to  the  OPFOR  vehicles  along  with  anything 
that  may  be  detected  from  each  OPFOR  vehicle,  one  must 
anticipate  the  possibility  that  an  OPFOR  position  may  mis¬ 
interpret  SIMCAT  cues  and  select  a  weapon  platform  to 
engage  a  target  that  could  not  be  detected  from  that  weapon 
platform.  This  could  happen,  for  example,  when  two  OPFOR 
vehicles  are  in  close  proximity.  A  target  is  detected  from 
one  OPFOR  vehicle  which  the  SIMCAT  appropriately  represents 
to  the  OPFOR  position.  The  OPFOR  position  could  mistakenly 
interpret  this  cue  and  specify  that  he  wishes  the  OPFOR 
vehicle  which  did  not  detect  the  target  to  engage  it. 

SIMCAT  must  permit  the  OPFOR  position  to  identify  the 
target  that  he  wishes  to  engage.  If,  as  a  result  of  misin¬ 
terpreting  SIMCAT  cues,  the  OPFOR  position  associates  the 
target  with  a  weapon  system  that  has  not  detected  the 
target  identified  by  the  OPFOR  position,  SIMCAT  must  pro¬ 
vide  the  OPFOR  with  appropriate  feedback. 

Once  a  battle  begins,  the  OPFOR  position  may  have  difficulty 
tracking  each  of  his  individual  vehicles  and  associated  weapon  systems. 
Therefore,  SIMCAT  must  have  the  capability  to  automatically  fire  OPFOR 
weapon  systems  should  the  OPFOR  position  desire  SIMCAT  to  do  so.  This 
simply  means  that  SIMCAT  should  perform  the  fire  control  processes  with¬ 
out  requiring  the  OPFOR  position  cueing  it  to  do  so  (i.e.,  when  an  OPFOR 
vehicle  detected  a  target,  it  would  automatically  engage  the  target  with 
the  most  appropriate  weapon  system  after  an  appropriate  time  delay). 

The  OPFOR  position  should  be  capable  of  designating  "automatic  fire 
control"  for  a  single  or  for  multiple  OPFOR  vehicles.  He  should  also  be 
permitted  to  switch  from  automatic  to  manual  fire  control  whenever  he 
desires  to  do  so. 
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Weapon  Effects  Modeling 
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The  functional  requirements  for  weapon  effects  can  be  viewed  as 
consisting  of  two  major  processes — determination  of  single  weapon 
effects  and  determination  of  aggregate  weapon  effects.  Each  will  be 
discussed  individually. 

When  one  or  more  weapon  systems  engage  a  single  target,  SIMCAT  must 
determine  the  effects  of  the  weapon  system(s)  firing  on  the  target 
engaged.  Two  subprocesses  are  Involved — hit  probabilities  and,  if  the 
target  is  hit,  consequential  damage  to  the  target.  At  a  minimum,  hit 
probabilities  must  consider  the  following  variables: 

•  Distance  to  target 

•  Type  of  target  (e.g.,  size  relative  to  what  it  is,  range, 
etc.) 

•  Target  disposition  (e.g.,  stationary  or  moving,  fully  or 
partially  exposed,  front/rear/ side  view)  Presence  (and 
degree  of)  or  absence  of  obscurants  (e.g. ,  smoke  dust) 

•  Firer  disposition  (e.g.,  stationary  or  moving,  using  TIS) 

After  having  determined  whether  or  not  the  target  was  hit,  SIMCAT 
must  next  determine  what  damage,  if  any,  the  target  suffered  as  a 
result.  It  should  not  be  assumed  that  a  target  is  destroyed  anytime  it 
is  hit.  For  example,  an  Ml  tank  that  receives  several  direct  hits  from 
a  73mm  gun  on  a  BMP  would  not  be  destroyed  in  most  cases.  However,  the 
possibility  does  exist  that  the  mobility  of  the  tank  may  be  affected  if 
a  road  wheel  is  damaged  or  destroyed  or  if  a  track  is  thrown.  There¬ 
fore,  SIMCAT  must  consider  the  following  variables  to  determine  the 
extent  of  damage  to  the  target  that  has  been  hit: 

•  Ballistics  of  impacting  munitions  (e.g.,  HEAT  main  gun 
round,  point  detonating  155mm,  73mm  HEAT) 

•  Number  of  rounds  impacting  (e.g.,  single  main  gun  HEAT 
round,  three  73nun  HEAT  rounds,  twenty  coax  rounds) 

•  Number  of  weapon  systems  engaging  target  (e.g,,  two  Ml 
tanks  may  simultaneously  engage  a  T72  or  BMP) 

•  Target  vulnerability  (e.g.,  the  target's  mobility,  turret, 
communications  capability) 

•  Target  type  (e.g.,  type  of  armor,  wheeled  or  tracked) 

In  addition  to  determining  single  weapon  effects,  a  set  of  force-on- 
force  aggregate  models  may  be  required  to  handle  larger  scale 
engagements  while  minimizing  processing  requirements.  Such  a  condition 
may  occur  in  an  intensified  situation  where,  for  example,  three  Ml  tanks 
and  two  BMPs  suddenly  are  exposed  to  one  another  simultaneously.  Should 
such  a  situation  occur,  it  may  be  beyond  the  processing  capability  of 
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SIMCAT  to  handle  simultaneous  firing  commands  from  three  Ml  tanks  and 
two  BMPs,  process  hit  probabilities,  and  determine  damage  to  targets 
hit.  Another  example  where  aggregate  models  definitely  will  be  required 
is  with  impacting  artillery,  where  the  number  of  targets  within  a  sheath 
and  number  of  impacting  rounds  must  be  considered. 


The  use  of  aggregate  models  for  weapon  effects  requires  SIMCAT  to 
compute  not  only  the  results  of  engagements,  but  also  their  duration. 
After  determining  the  expected  duration  and  the  loss  rates  over  time  at 
the  start  of  a  force-on-force  engagement,  SIMCAT  must  allow  for  the 
possibility  that  intervening  events  will  affect  the  outcome.  Specifi¬ 
cally,  this  allows  the  SIMCAT  OPFOR  and  trainee  positions  to  take  some 
sort  of  action,  such  as  attempting  to  disengage,  withdrawing,  or 
possibly  requesting  indirect  fire  support  rather  than  simply  being 
forced  to  accept  a  predetermined  outcome  for  the  engagement. 


Representation  Requirements 

The  controller/trainer ,  trainee,  and  OPFOR  engagement  representa¬ 
tion  requirements  for  SIMCAT  are  functionally  identical,  but  they  will 
vary  dramatically  in  the  manner  in  which  they  are  satisfied.  Therefore, 
the  engagement  representation  requirements  will  be  discussed  first  in 
terms  of  their  functions  that  will  be  common  to  all  SIMCAT  positions. 
Following  that,  the  differences  in  the  manner  in  which  engagement 
representations  will  be  satisfied,  depending  on  the  SIMCAT  position 
involved,  will  be  addressed. 

The  engagement  representation  requirements  for  SIMCAT  fall  into 
three  basic  categories — weapon  firing,  impact  of  weapon  rounds,  and 
effect,  if  any,  of  impacting  rounds.  Specifically,  these  requirements 
dictate  that  SIMCAT  represent  the  following: 

•  The  weapon  platform  that  is  firing  -  The  system  must  indi¬ 
cate  whether  a  BMP,  T72,  or  Ml  tank  is  firing. 

•  The  weapon  system  aboard  the  platform  that  is  firing  -  The 
system  must  indicate  whether  it  is  the  coax  or  main  gun 
that  is  being  fired  on  an  Ml  tank,  and  whether  it  is  the 
SAGGER  or  the  73mm  gun  that  is  being  fired  on  a  BMP.  In 
the  case  of  the  T72,  it  will  always  be  assumed  that  the 
main  gun  is  being  fired. 

•  The  impact  of  weapon  system  rounds  -  Auditory  and  visual 
cues  resulting  from  rounds  impacting  down  range  will  be 
provided  to  appropriate  SIMCAT  positions.  The  positions 
will  include  not  only  the  weapon  system  that  fired,  but  any 
friendly  and  OPFOR  vehicles  that  can  detect  the  impacting 
rounds. 

•  Weapon  signatures  -  SIMCAT  must  provide  appropriate  audi¬ 
tory  and  visual  cues  to  all  SIMCAT  vehicles  that  could 
detect  the  signature  of  a  weapon. 
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•  Weapon  firing  -  As  appropriate,  SIMCAT  positions  must  be 
made  aware  of  when  one  of  their  weapon  systems  has  initi¬ 
ated  firing  and  when  it  has  ceased  firing. 

•  In-Flight  representations  -  Cues  resulting  from  tracers  and 
SAGGER  ATGMs  in  flight  must  be  represented  to  appropriate 
SIMCAT  positions  (providing  cues  not  only  to  the  individual 
who  fires  the  weapon,  but  to  those  individuals  who  could 
detect  such  cues) . 

•  Weapon  effects  -  SIMCAT  positions  should  receive  visual  and 
auditory  cues  that  would  result  from  the  target  being  hit 
(e.g.,  burning  BMP,  T72  being  blown  up,  round  impacting 
short/long/left/right).  This  requirement  should  not  be 
interpreted  to  mean  that  the  actual  weapon  effect (s)  would 
be  divulged  to  a  SIMCAT  position.  For  example,  should  a 
HEAT  round  hit  but  not  penetrate  a  tank  turret,  the  result¬ 
ing  cue  would  probably  be  restricted  to  a  flash,  a  bang, 
and  some  smoke  in  the  proximity  of  the  turret  that  was  hit. 

If  the  turret  is  frozen  as  a  result  of  the  hit,  only  the 
occupants  of  the  tank  that  was  hit,  not  the  position  firing 
the  HEAT  round,  would  be  aware  of  this  consequence. 

Given  that  each  SIMCAT  positions  will  have  a  different  perception1 
of  the  battlefield,  the  manner  in  which  engagement  representations  will 
be  provided  to  each  position  will  vary.  For  example,  consider  the 
engagement  representation  requirements  for  the  Ml  tank.  SIMCAT  must 
represent  the  Ml  weapon  system  that  is  firing  (i.e.,  coax  or  tank  main 
gun).  SIMCAT  will  represent  this  differently  to  each  SIMCAT  position  in 
the  following  ways : 

•  Trainee  Position  -  SIMCAT  will  probably  provide  varying 
auditory  cues  to  represent  which  of  the  Ml  weapon  systems 
is  firing.  Visual  representations  of  rounds  in-flight 
(e.g.,  tracers  from  the  coax),  impacting  rounds,  and  weapon 
effects  (e.g.,  dust,  primary  and/or  secondary  explosions, 
fire,  smoke)  will  be  provided  to  the  trainee  from  the 
perspective  of  the  tank  itself. 

•  Controller/Trainer  Position  -  The  controller /trainer  will 
never  need  to  be  provided  with  auditory  cues  resulting  from 
the  firing  of  an  Ml  tank.  Nor  will  the  controller/trainer 
need  to  be  provided  with  visual  representations  from  the 
perspective  of  the  Ml  tank  actually  firing.  However,  the 
controller/trainer  will  need  representations  which  will 


Perception  of  the  battlefield  from  the  trainee  position  will  be 
restricted  to  a  view  from  a  single  Ml  tank;  perception  from  the  OPFOR 
position  will  be  a  bird's-eye  view  of  all  of  his  vehicles;  and  percep¬ 
tion  from  the  controller/trainer  position  will  be  a  view  of  the  entire 
battlefield  and  will  include  all  OPFOR  and  friendly  vehicles  involved. 
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enable  him  to  determine  which  of  the  four  Ml  tanks  is 
firing  and  which  weapon  system  is  being  fired  (i.e. ,  coax 
or  main  gun).  Unlike  the  trainee  whose  tank  is  firing,  the 
controller/trainer  does  not  need  the  auditory  nor  ground 
level  perception  representations  of  these  conditions. 
Instead,  these  conditions  may  be  represented  symbolically. 

•  OPFOR  -  The  OPFOR  position  in  this  example  would  be  pro¬ 
vided  with  appropriate  visual  and  auditory  cues  depending 
upon  the  detection/identification  variables  discussed 
previously.  When  an  OPFOR  vehicle  engages  a  target  (i.e., 
with  a  T72  main  gun  or  with  either  a  73mm  gun  or  SAGGER 
from  a  BMP) ,  engagement  representations  to  the  OPFOR  posi¬ 
tions  should  be  quite  different  from  those  provided  to  a 
trainee  position  when  an  Ml  weapon  system  fires.  SIMCAT 
will  portray  all  of  the  OPFOR  vehicles  simultaneously. 
Therefore,  when  an  OPFOR  vehicle  engages  a  target,  SIMCAT 
must  represent  to  the  OPFOR  position  which  weapon  platform 
is  firing  (i.e.,  which  BMP  or  T72)  and,  if  it  is  a  BMP, 
whether  the  SAGGER  or  73mm  gun  is  firing.  These  represen¬ 
tation  requirements  may  be  satisfied  through  some  form  of 
symbology.  The  approach  used  to  make  these  representations 
to  the  OPFOR  position  would  also  satisfy  the  controller/ 
trainer  OPFOR  engagement  representation  requirements. 


Indirect  Fire 


Dedicated  indirect  fire  support  will  be  provided  to  both  friendly 
(i.e.,  155mm)  and  OPFOR  (i.e.,  152mm)  forces  in  all  SIMCAT  scenarios. 

To  satisfy  its  indirect  fire  functional  requirements,  SIMCAT  must  main¬ 
tain  a  record  of  indirect  fire  allocations,  provide  a  means  for  both  the 
friendly  and  OPFOR  forces  to  request  indirect  fire  support,  deliver/ 
impact  indirect  fires,  and  represent  the  effects  of  indirect  fire  to  all 
SIMCAT  positions.  Each  of  these  requirements  will  be  discussed  indi¬ 
vidually. 


Fire  Support  Allocations 

No  weapon  system  found  on  the  battlefield  has  an  inexhaustible 

supply  of  munitions.  As  a  result,  weapon  system  usage  should  be 
tempered  and  controlled.  These  are  difficult  skills  to  teach  and  to 
learn  because  soldiers  tend  not  to  be  concerned  with  such  matters  in 
combat.  However,  this  is  a  reality  of  combat  that  SIMCAT  must  address 
if  it  is  to  avoid  negative  training. 


In  a  real  tactical  situation,  the  only  information  provided  to 
tactical  or  maneuver  unit  leaders  regarding  indirect  fire  is  whether  or 
not  it  exists  and,  if  it  does  exist,  whether  or  not  it  Is  dedicated 
support  and  the  number  of  batteries  supporting  them.  The  point  here  is 
that  the  leaders  are  never  Informed  of  the  number  of  rounds  that  are 
available  for  their  support.  However,  the  number  of  rounds  available  is 
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restricted  minimally  to  the  basic  load  of  the  batteries  supporting  them. 
Therefore,  SIMCAT  must  place  a  ceiling  on  the  number  of  rounds,  by  fuze 
type,  that  are  available  to  support  both  the  OPFOR  and  friendly  forces. 
This  allocation  will  never  be  provided  in  total  to  either  the  OPFOR  or 
friendly  forces.  However,  SIMCAT  will  monitor  the  number  of  rounds 
fired  and  the  number  of  rounds  remaining.  When  the  supply  has  been 
exhausted,  SIMCAT  will  make  appropriate  notifications  (for  example,  to 
the  controller/trainer  as  well  as  to  TC,  that  all  of  his  artillery 
allocation  has  been  exhausted) . 

It  is  difficult  to  determine  the  number  of  rounds  by  fuze  type  that 
should  be  allocated  to  OPFOR  and  friendly  forces.  Many  variables  must 
be  considered,  including  number  of  batteries  in  support,  size  of  artil¬ 
lery  (e.g.,  155mm,  105mm) ,  basic  loads,  mission  of  maneuver  units  being 
supported,  and  combat  conditions  experienced  to  date  by  both  supporting 
artillery  and  maneuver  units  Involved.  Most  military  personnel  would 
agree  that  it  is  difficult,  if  not  Impossible,  to  identify  any  norm(s) 
considering  the  number  of  variables  Involved  and  their  permutations. 
However,  the  idea  of  an  Inexhaustible  supply  of  indirect  fire  support  is 
unrealistic.  Therefore,  ceilings  on  the  number  of  rounds  available  by 
fuze  type  must  be  established  for  SIMCAT.  These  are  specified  in  Table 
2  below. 

The  allocations  specified  In  Table  2  are  the  maximum  number  of 
rounds  that  OPFOR  and  friendly  forces  can  be  allocated  during  any 
scenario.  The  controller/trainer  will  have  the  capability  to  decrease 
the  allocations  as  he  sees  fit  during  initialization  of  the  simulation, 
but  he  will  not  be  permitted  to  allocate  more  artillery  than  that 
specified  in  the  table. 


Table  2 

Indirect  Fire  Support  Allocations  by  Fuze  Type,  Mission,  and  Force 


NUMBER  OF  ROUNDS  ALLOCATED  BY 
FRIENDLY  FORCE'S  MISSION 

FUZE  TYPE  Movement  To  Contact  Hasty  Attack  Defense 

Friendly  (155rcm) : 

DPIC  60  60  40 

White  Phosphorus  24  24  20 

OPFOR  (152mm): 


High  Explosive,  Quick 
White  Phosphorus 


50 

None 


50 

None 


200 
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Friendly  Force  Indirect  Fire  Requests 


Armor  platoon  leaders  normally  request  indirect  fire  support  in  one 
of  two  ways:  either  by  direct  contact  with  a  Fire  Direction  Center 
(FDC)  using  formal  call  for  fire  procedures,  or  through  communications 
with  a  FIST  FO  (Fire  Support  Team  Forward  Observer)  assigned  to  his 
company  team.  In  the  latter  case,  formal  call  for  fire  procedures  are 
not  required  and  communications  are  regimented  by  sequencing  or  content 
protocols.  The  initial  version  of  S1MCAT  will  not  concern  Itself  with 
platoon  leader /FDC  call  for  fire.  All  Indirect  fire  support  requests 
will  be  handled  through  communications  between  the  platoon  leader  and/or 
the  platoon  sergeant  and  a  FIST  FO.  To  define  the  functional  require¬ 
ments  associated  with  friendly  force  indirect  fire  support,  two  areas 
will  be  addressed.  The  first  area  is  concerned  with  the  requirements 
associated  with  requesting  an  indirect  fire  mission.  The  second  is  the 
manner  in  which  the  requests  are  actually  processed. 

•  Indirect  Fire  Requests  -  When  either  the  platoon  leader  or 
the  platoon  sergeant  decides  to  request  an  indirect  fire 
mission,  he  first  will  establish  contact  with  the  Company 
Team's  FIST  FO.  This  will  be  done  on  the  Company  Team  Net. 

The  role  of  the  FIST  FO  will  be  assumed  by  the  SIMCAT 
controller /trainer. 

It  will  always  be  assumed  that  the  FIST  FO  can  observe  the 
target  that  the  platoon  leader  or  platoon  sergeant  is 
attempting  to  engage  with  indirect  fire.1  Therefore,  when 
an  indirect  fire  request  is  made,  the  platoon  leader  or 
platoon  sergeant  need  only  identify  the  target  and  specify 
its  location  by  providing  a  Spot  Report  to  the  FIST  FO  on 
the  company  net,  ending  with  a  request  for  indirect  fire. 

In  a  real  situation,  formal  call  for  fire  requests  communi¬ 
cated  to  an  FDC  would  then  become  the  responsibility  of  the 
FIST  FO.  In  addition,  the  FIST  FO  would  make  any  subse¬ 
quent  adjustments  necessary  to  get  the  indirect  fire  on 
target.  These  adjustments  do  not  (and  in  SIMCAT,  will  not) 
require  any  communications  between  the  platoon  leader  or 
platoon  sergeant  and  the  FIST  FO. 

Given  that  the  controller/trainer  will  assume  the  role  of 
the  FIST  FO,  it  will  be  his  responsibility  to  ensure  the 
indirect  fire  request  received  from  the  platoon  leader  or 

platoon  sergeant  is  properly  processed. 


^his,  in  fact,  will  be  the  case  because  the  controller /trainer  (acting 
as  the  FIST  FO)  will  have  a  bird's-eye  view  of  the  battle.  Therefore, 
the  controller /trainer  will  be  capable  of  accurately  interpreting 
platoon  requests  made  by  the  platoon  leader  or  the  platoon  sergeant. 


< 
I 


•  Request  Processing  -  Having  received  an  indirect  fire 

request  from  either  the  platoon  leader  or  platoon  sergeant, 
the  controller/  trainer  (acting  as  the  FIST  FO)  will  be 
responsible  for  actually  processing  the  request.  There¬ 
fore,  the  controller/trainer  must  be  able  to  specify  the 
following  to  the  system: 

-  coordinates  or  adjustments 

-  fuze  type 

-  direction  (in  mils) 

-  number  of  batteries  or  rounds  to  be  fired 

It  is  not  being  suggested  that  formal  call  for  fire  procedures  be 
established  between  the  controller /trainer  and  SIMCAT.  To  the  contrary, 
the  simplest  and  most  expedient  means  of  conveying  this  information  to 
SIMCAT  is  necessary  to  avoid  overburdening  the  controller/trainer.  The 
use  of  light  pens  or  touch-sensitive  screens  would  be  ideal,  but  may  not 
be  feasible  considering  SIMCAT  cost  constraints.  Other  alternatives 
which  would  expedite  the  input  of  indirect  fire  data  would  include  the 
use  of  "f ill-in-the-blank"  forms  or  menus  depicted  on  the  controller/ 
trainer  screen  (monitor) .  Another  way  to  expedite  this  process  would  be 
to  include  grid  lines  on  the  controller/trainer  terrain  representations. 
These  alternatives  should  be  among  those  Identified  and  considered. 

Given  the  likelihood  that  the  controller/trainer  will  be  over¬ 
burdened  with  processing  indirect  fire  requests  (especially  adjustments 
following  an  initial  request) ,  it  will  be  necessary  for  SIMCAT  to  auto¬ 
matically  make  any  adjustments  following  an  initial  request  for  fire 
input  to  SIMCAT  by  the  controller/trainer .  SIMCAT  will  be  able  to  do 
this  because  it  will  know  where  the  indirect  fire  targets  are,  where  the 
initial  request  impacted,  and,  therefore,  what,  if  any,  subsequent 
adjustments  are  necessary.  SIMCAT  must  also  consider  and  reflect  any 
time  delays  associated  with  adjustments  and  the  human  inaccuracies 
associated  with  such  adjustments  (e.g.,  seldom,  if  ever,  would  the 
initial  adjustment  result  in  the  indirect  fire  impacting  directly  on  the 
target — especially  if  it  is  moving) . 


OPFOR  Indirect  Fire  Requests 

Given  that  there  are  no  training  objectives  associated  with  the 
OPFOR,  the  fidelity  of  the  procedures  associated  with  requesting 
indirect  fire  support  is  of  no  concern.  In  addition,  because  there  is 
concern  about  limiting  the  procedural  burdens  placed  on  the  controller/ 
trainer,  the  manner  in  which  the  OPFOR  requests  indirect  fire  support 
will  differ  greatly  from  the  way  the  friendly  forces  request  indirect 
fire  support. 

The  individual  occupying  the  SIMCAT  OPFOR  position  should  not  be 
required  to  communicate  with  anyone  to  request  indirect  fire  support. 

It  is  proposed  that  the  same  procedure  followed  by  the  controller/ 
trainer  to  process  a  friendly  force  indirect  fire  request  be  used  by  the 


OPFOR.  That  is,  he  should  be  able  to  input  the  appropriate  indirect 
fire  data  (e.g.,  coordinates,  direction)  directly  into  SIMCAT  using  the 
same  simple,  expedient  means  used  by  the  controller/trainer  for  friendly 
force  fire  requests.  In  addition,  as  was  the  case  with  friendly  force 
indirect  fire  requests,  SIMCAT  should  automatically  make  any  required 
adjustments  following  an  initial  call  for  fire  request. 


Indirect  Fire  Delivery 


Once  the  SIMCAT  system  has  received  an  indirect  fire  request  (from 
either  the  controller/trainer  or  OPFOR),  it  must  process  the  request. 
Specifically,  these  functional  requirements  involve  the  following: 

•  Determining  the  eventual  impact  area  of  the  requested  fire 
in  relation  to  the  locations  of  all  OPFOR  and  friendly 
force  vehicles. 

•  Given  the  aforementioned,  determining  which  of  the  OPFOR 
and  friendly  force  vehicles  should  be  provided  with  audi¬ 
tory  and/or  visual  cues. 

•  Appropriate  timing  of  the  events  associated  with  an 
indirect  fire  request  (i.e.,  time  from  request  to  shot, 
time  from  shot  to  splash). 

•  Providing  the  indirect  fire  requestor  (i.e.,  controller/ 
trainer  or  OPFOR)  with  both  "Shot”  and  "Splash"  messages  at 
the  appropriate  times. 

•  Maintaining  a  count  of  the  number  of  rounds  (by  fuze  type) 
expended  and  remaining  (for  each  force)  and,  when  alloca¬ 
tions  have  been  expended,  informing  requestor  (i.e.,  OPFOR 
and  controller/trainer)  accordingly. 

•  Providing  the  appropriate  visual  and  auditory  cues 
(discussed  in  detail  in  the  next  section) . 

•  Assessing  the  effects,  if  any,  on  targets  located  in  the 
Impact  area  and  providing  appropriate  cues  accordingly. 


Representation  Requirements 

As  stated  previously,  once  SIMCAT  has  determined  where  indirect 
fire  should  impact  and  has  determined  who  or  what  can  detect  the  impact¬ 
ing  fire,  SIMCAT  must  represent  the  appropriate  cues  to  certain  SIMCAT 
positions.  To  determine  who  can  detect  the  impacting  fire,  the 
following  factors  must  be  considered: 


•  Line  of  sight,  which  involves  terrain  relief  and  vegeta¬ 
tion,  as  well  as  presence  and  degree  of  any  obscurants. 


•  Range  from  Impacting  fire  to  possible  detector. 

Number  of  batteries  fired  (i.e.,  number  of  rounds  impact¬ 
ing)  . 

•  Fuze  types  (including  smoke). 

•  Sheath  or  pattern  in  which  the  indirect  fire  is  impacting 
(for  purposes  of  SIMCAT,  it  will  be  assumed  a  normal  sheath 
is  always  used) . 

These  detection  criteria  will  differ  to  some  degree  depending  upon 
whether  a  visual  or  an  auditory  cue  requirement  is  being  considered  by 
SIMCAT.  For  example,  if  a  tank  (in  a  defensive  position  with  its  engine 
off)  is  on  one  side  of  a  hill,  and  artillery  Impacts  on  the  other  side, 
there  is  no  question  that  a  visual  cue  would  not  be  appropriate. 

However,  it  can  also  be  concluded  that  the  occupant (s)  of  that  tank 
should  be  provided  with  some  form  of  auditory  cue. 

Impacting  fire  may  result  in  a  requirement  for  SIMCAT  to  represent 
either  a  visual  or  auditory  cue,  or  possibly  both,  to  SIMCAT  positions. 
The  criteria  regarding  what  would  be  represented  should  consider  the 
same  factors  discussed  in  detail  in  the  section  on  the  SIMCAT  detection/ 
identification  functional  requirements.  These  criteria  differentiate 
between  detection  and  identification;  although  a  visual  or  auditory 
impacting  fire  cue  may  be  detectable,  its  identification  is  dependent 
upon  other  variables  (primarily  range).  As  a  result,  there  may  be  a 
requirement  for  several  impacting  fire  auditory  and  visual  cues.  For 
example,  fire  impacting  200  meters  away  would  sound  different  from  fire 
impacting  2,000  meters  away,  and  both  would  look  different. 


Communication 


The  communication  functional  requirements  for  SIMCAT  serve  three 
primary  purposes.  First,  they  will  permit  the  controller /trainer  to 
interact  with  other  SIMCAT  positions  in  order  to  control  the  simulation. 
Second,  they  will  permit  the  controller/trainer  to  monitor  tactically 
related  communications  for  evaluation  and  feedback  purposes.  Third, 
they  will  provide  SIMCAT  trainees  with  a  realistic  tactical  communica¬ 
tions  environment.  Realism  in  this  context  means  that  the  communication 
networks,  the  participants  in  those  networks  (i.e.,  SIMCAT  positions  and 
roles  simulated  by  SIMCAT),  and  the  means  of  communicating  found  in 
field  tactical  environments  will  be  represented  in  SIMCAT.  Communica¬ 
tion  functional  requirements  are  divided  into  five  different  areas: 

(1)  Communication  Network  Participants,  (2)  Communication  Networks, 

(3)  Communication  Network  Selection  (4)  Hand  and  Arm  Signals,  and 
(3)  Jamming. 


Communication  Network  Participants 


To  understand  the  communication  requirements  for  SIMCAT,  it  is 
first  necessary  to  know  what  positions  or  roles  will  be  communicating  in 


each  network  as  well  as  who  or  what  will  be  assuming  these  roles.  There 
are  seven  positions  or  participants  involved  in  the  communication  net¬ 
works  required  by  SIMCAT.  It  should  be  noted  that  all  seven  of  these 
participants  will  never  be  involved  together  in  any  single  SIMCAT  com¬ 
munications  network  (this  will  be  explained  in  greater  detail  in  the 
next  section).  Specifically,  the  participants  involved  and  whoever  or 
whatever  will  assume  these  participatory  roles  are  as  follows: 

•  Trainees  -  These  include  the  platoon  leader,  platoon 
sergeant,  TCI,  and  TC2.  The  communications  requirements  of 
these  individuals  will  be  restricted  to  those  normally 
associated  with  their  positions  in  a  tactical  situation. 

•  Controller /Trainer  -  The  controller/trainer  will  have  the 
ability  to  communicate  with  all  trainees  (individually  and 
collectively)  as  well  as  with  the  individual  occupying  the 
OPFOR  position.  The  purpose  of  these  communications  is  to 
control  the  simulation,  provide  feedback,  and  monitor  com¬ 
munication  activity. 

•  OPFOR  -  The  individual  playing  the  role  of  the  OPFOR  must 
be  provided  with  a  means  of  communicating  with  the  con¬ 
troller/  trainer.  Most  of  these  communications  will  be 
related  to  simulation  control. 

•  Tank  Driver  -  The  tank  driver  of  concern  here  is  the  driver 
of  the  tank  controlled  by  each  trainee,  but  not  the  driver 
of  any  tank  controlled  by  the  OPFOR.  The  driver  of  a 
trainee-controlled  tank  will  be  a  simulated,  computer- 
controlled  role  capable  of  recognizing  TC  driving  commands 
(related  to  direction  and  rate  of  movement)  and  able  to 
produce  minimal  voice  outputs.  Specific  requirements  of 
this  role  are  addressed  in  detail  in  the  section  on  the 
movement  functional  requirements  for  SIMCAT. 

•  Gunner/Loader  -  The  gunner/loader  of  concern  here  is  the 
gunner/  loader  of  the  tank  controlled  by  each  trainee,  but 
not  the  gunner/  loader  of  any  tank  controlled  by  the  OPFOR. 

The  gunner/loader  of  a  trainee-controlled  tank  will  be  a 
simulated,  computer-controlled  role  capable  of  recognizing 
firing  commands  and  able  to  produce  minimal  voice  outputs 
(i.e.,  "Identified"  and  "Up").  Specific  voice  input/output 
requirements  are  addressed  in  detail  in  the  discussion  of 
the  engagement  functional  requirements  for  SIMCAT. 

•  FIST  FO  -  The  role  of  the  FIST  FO  will  be  assumed  by  the 
controller/  trainer  in  the  required  communication  network. 

The  function  of  this  role  will  be  to  receive  and  process 
indirect  fire  requests  from  the  friendly  force  platoon 
leader  and/or  platoon  sergeant. 


•  Company  Team  Leader  -  The  role  of  the  friendly  force 
company  team  leader  will  be  assumed  by  the  controller/ 
trainer.  The  function  of  this  role  will  be  to  provide 
normal  company  team  leader  communications  to  the  friendly 
force  platoon  leader  and/or  platoon  sergeant. 

Communication  Networks 

For  the  purpose  of  this  discussion,  communication  networks  or  nets 
will  be  discussed  in  terms  of  the  participants  who  are  to  be  provided 
with  a  capability  to  communicate  with  one  another  on  the  net  and  the 
purpose  that  the  net  is  intended  to  serve.  SIMCAT  requires  four  commun¬ 
ication  nets:  Platoon,  Company  Team,  Tank  Intercom  (four  each),  and 
Controller.  Because  four  independent  and  separate  tank  intercom  nets 
are  involved,  SIMCAT  can  be  thought  of  as  requiring  seven  communication 
nets  (especially  from  a  system  development  view).  However,  each  of  the 
four  tank  intercom  nets  are  functionally  identical.  Therefore,  these 
nets  will  be  regarded  as  one. 

The  purpose  of  the  four  main  communication  nets  are  as  follows: 

•  Platoon  -  Tactical  operations  net  used  by  all  members  of 
tank  platoon  (i.e.,  trainees)  for  C3  functions. 

•  Company  Team  -  Tactical  operations  net  enabling  communica¬ 
tions  between  all  vehicles  of  the  company  team.  The 
primary  purpose  of  this  net  for  SIMCAT  is  to  enable  the 
controller/  trainer  to  role  play  a  company  team  leader  and 
FIST  FO,  thus  providing  the  necessary  interface  in  these 
roles  with  the  platoon  leader  and/or  platoon  sergeant. 

•  Tank  Intercom  -  Involves  satisfying  communication  require¬ 
ments  among  each  tank  driver,  gunner/ loader ,  and  TC.  The 
primary  purpose  of  this  net  in  SIMCAT  is  control  of  move¬ 
ment  and  fire. 

•  Controller  -  Used  solely  for  simulation  control  purposes, 
this  net  permits  communications  between  the  controller/ 
trainer  and  OPFOR. 

Table  3  provides  the  specifications  for  each  of  the  required  SIMCAT 

communication  nets.  The  first  column  specifies  the  communication  net 
(as  described  above).  The  second  column  identifies  the  net  participants 
(described  earlier).  It  should  be  noted  that  a  net  participant  can  be 
either  an  individual  occupying  a  SIMCAT  position  (i.e.,  trainee, 
controller/trainer,  OPFOR),  or  a  computer-controlled  role.  All  partici¬ 
pants  will  be  permitted  to  transmit,  receive/monitor,  or  both  transmit 
and  receive/monitor. 


Table  3 


SIMCAT  Communication  Network  Requirements 


Communication  Network 

g 

Platoon 


Company  Team 


Tank  Intercom 


c 


Controller 


Network  Participants 

Platoon  Leader  ^ 

Platoon  Sergeant 
TCI  and  TC2 
Controller /Trainer 

Platoon  Leader*3  ^ 

Platoon  Sergeant 
Controller /Trainer 
FIST  FO  (role-played  by 
controller /trainer) 

Company  Team  Leader  (role-played 
by  controller/trainer) 

TC  (i.e. ,  platoon  leader, 

platoon  sergeant,  TCI  and  TC2 
Gunner/Loader  (computer- 
controlled  voice  I/O) 

Driver  (computer-controlled 
voice  I/O) 

OPFOR 

Controller /Trainer 


aln  SIMCAT,  this  net  will  be  used  to  simulate  both  the  radio  Platoon  Net 
and  the  Hot  Loop  or  wire  communication  network  used  when  the  friendly 
platoon  is  in  defensive  positions. 

^The  Platoon  Leader  and  Platoon  Sergeant  trainee  positions  must  be 
capable  of  monitoring  the  Platoon  and  Company  Team  Nets  simultaneously. 
However,  they  should  be  able  to  transmit  on  only  one  net  at  any  given 
time. 

£ 

Four  tank  intercom  nets  (one  for  each  tank)  are  required.  Each  of 
these  nets  must  be  independent  of  the  other. 


Communication  Net  Selection 


The  controller/trainer,  platoon  leader,  and  platoon  sergeant  posi¬ 
tions  in  SIMCAT  will  have  the  capability  to  access  several  different 
communication  nets  (see  Table  3) .  Therefore,  each  of  these  individuals 
must  be  provided  with  a  means  of  selecting  the  communication  net  in 
which  he  wishes  to  transmit  and/  or  receive/monitor. 
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The  platoon  leader  and  platoon  sergeant  must  be  able  to  select  and 
then  access  one  of  three  SIMCAT  nets:  Platoon  Net,  Company  Team  Net, 
and  their  individual  Tank  Intercom  Net.  Specifically,  their  communica¬ 
tion  net  selection  requirements  dictate  that  they  have  the  capability 
to: 

•  Simultaneously  monitor  both  the  Company  Team  and  Platoon 
Nets. 

•  Select  one  of  three  communication  networks  on  which  to 
transmit — Tank  Intercom,  Platoon,  or  Company  Team.  They 
should  not  be  permitted  to  transmit  on  more  than  one  net  at 
any  given  time. 

Each  TC  must  be  capable  of  selecting  and  then  transmitting  and 
receiving  on  one  of  two  nets:  Platoon  Net  or  Tank  Intercom  Net.  Spe¬ 
cifically,  each  TC  must  be  capable  of: 

•  Selecting  either  the  Tank  Intercom  Net  or  Platoon  Net  to 
monitor. 

•  Transmitting  on  either  net,  but  not  simultaneously  on  both. 

The  controller/trainer  net  selection  requirements  dictate  that 
SIMCAT  provide  the  controller /trainer  with  the  capability  to: 

•  Monitor  the  Platoon  Net  and  Company  Team  Net. 

•  Simultaneously  monitor  the  Platoon  Net,  Company  Team  Net, 
and  Controller  Net. 

•  Transmit  to  each  trainee  position  simultaneously  over  the 
Platoon  Net. 

•  Select  any  one  of  three  SIMCAT  communication  networks  on 
which  to  transmit:  Platoon  Net,  Company  Team  Net,  or 
Controller  Net. 


Hand  and  Arm  Signals 


When  tank  platoons  are  involved  in  offensive  operations,  hand  and 
arm  signals  are  often  used  for  tank  platoon  communications.  Although 
they  may  occur  less  frequently,  they  are  also  used  by  tank  platoons  in 
defensive  operations.  Given  their  frequency  and  the  ever  present  need 
for  secure  communication  networks,  it  is  imperative  that  SIMCAT  permit 
and  facilitate  the  use  of  hand  and  arm  signals.  Specifically,  SIMCAT 
must  provide  each  of  the  trainees  the  ability  to: 

•  Choose  from  10  to  20  hand  and  arm  signals  he  wishes  to 
send. 

•  Send  a  selected  hand  and  arm  signal. 


*  Select  the  recipient  (there  may  be  more  than  one)  of  a 
hand  and  arm  signal. 

*  Receive  hand  and  arm  signals. 

*  Recognize  or  determine  from  whom  the  hand  and  arm  signal 
is  coming. 

*  Witness  or  observe  hand  and  arm  signals  being  passed 
between  two  tanks  other  than  his  own. 

The  specific  hand  and  arm  signals  to  be  incorporated  in  SIMCAT  have  yet 
to  be  determined;  they  will  vary  depending  upon  the  reference  source 
used.  However,  it  is  known  that  there  will  be  a  minimum  of  10  and  a 
maximum  of  20  involved. 


Jammini 


Electronic  Warfare  (EW)  is  a  very  real  threat  on  the  modern  battle¬ 
field  and  will  be  experienced  at  all  Army  echelons  in  combat. 

Therefore,  jamming  of  SIMCAT  communication  networks  must  be  considered. 
As  currently  envisioned,  SIMCAT' s  jamming  functional  requirements  will 
involve  the  following: 


•  All  jamming  will  be  controlled  by  the  controller/trainer . 
The  controller/trainer  must  be  provided  with  the  ability  to 
select  the  SIMCAT  communication  network  to  be  jammed 
(selection  alternatives  would  be  restricted  to  the  Platoon 
and  Company  Team  Nets) . 


•  The  controller/trainer  must  have  the  ability  both  to  initi¬ 
ate  and  terminate  the  jamming  of  a  net. 


•  Although  jamming  can  manifest  itself  on  a  radio  net  in  a 
variety  of  ways  (e.g.,  gulls,  random  noise,  wobbler, 
stepped  tones) ,  SIMCAT  will  be  required  to  simulate  only 
one  manifestation. 


Resources  Audit 


More  often  than  not,  events  on  a  battlefield  are  a  function  of  the 
resources  (e.g.,  weapons,  food,  fuel)  available  to  the  combatants 
involved.  These  resources  are  not  inexhaustible  and,  once  expended,  can 
change  the  course  of  a  battle.  The  resources  of  concern  to  a  military 
leader  vary,  depending  primarily  on  variables  such  as  time  and  distances 
involved.  For  example,  a  division  commander  would  have  to  concern  him¬ 
self  about  food  in  a  major  operation  involving  several  days.  A  platoon 
leader,  on  the  other  hand,  would  not  concern  himself  about  food  given  a 
movement  to  contact  or  hasty  attack  mission  involving  short  distances 
and  short  duration.  However,  both  the  division  commander  and  platoon 


leaders,  in  the  examples  given,  would  be  concerned  about  other 
resources,  such  as  munitions. 

SIMCAT  must  be  sensitive  to  resources  critical  to  the  scenarios  it 
will  simulate.  This  sensitivity  is  imperative  if  negative  training  is 
to  be  avoided.  For  example,  if  a  single  Ml  Abrams  tank  is  permitted  to 
fire  50  HEAT  rounds  in  a  SIMCAT  simulation  (which  far  exceeds  its  basic 
load  of  HEAT) ,  negative  training  would  be  likely  to  result.  Therefore, 
SIMCAT  must  maintain  an  audit  of  friendly  force  and  OPFOR  resources 
(i.e.,  what  they  started  with,  what  has  been  expended,  what  remains,  and 
when  a  resource  has  been  exhausted) . 

An  inventory  of  possible  military  resources  would  be  an  ambitious 
undertaking  to  develop  as  well  as  to  reflect  in  the  design  of  SIMCAT. 
However,  as  stated  previously,  the  resources  about  which  one  should  be 
concerned  vary  depending  on  the  nature  of  the  military  mission  (e.g., 
duration,  distances)  under  question.  In  SIMCAT,  the  focus  will  be  on 
armor  platoon  missions  or  operations  involving  relatively  short  periods 
of  time  and  short  traveling  distances  (e.g.,  10  to  40  kilometers). 
Therefore,  only  munitions  (i.e.,  basic  loads  and  expenditures  of  weapon 
systems  involved)  and  fuel  resources  (i.e.,  fuel  capacities  and  fuel 
consumption  rates  of  vehicles  involved)  will  be  of  concern.  Each  of 
these  resources  and  their  resource  audit  functional  requirements  will  be 
discussed  individually. 


Fuel  Resource  Audit  Requirements 

SIMCAT  should  maintain  an  audit  of  the  amount  of  fuel  used  per  unit 
of  distance  traveled  and/or  per  unit  of  time  while  idling;  though  an  Ml 
consumes  approximately  an  equal  amount  of  fuel  whether  moving  or  idling, 
this  may  not  be  true  for  other  vehicles.  This  requirement  can  be 
expressed  in  terms  of  a  2  X  N  table  where  N  equals  the  number  of  dis¬ 
tinct  types  of  fuel  users  (e.g..  Ml,  T72,  BMP).  The  first  entry  for 
each  fuel  user  type  represents  the  fuel  consumption  for  a  given  unit  of 
distance  traveled.  Fuel  consumption  rates  (while  vehicle  is  moving)  can 
be  held  constant  regardless  of  such  things  as  movement  rate,  relief,  and 
other  factors  which  have  only  a  marginally  different  effect  on  fuel 
consumption.  The  second  entry  for  each  fuel  user  type  represents  the 
fuel  consumption  for  a  given  unit  of  time  while  idling.  Of  course,  fuel 
consumption  rates  while  idling  will  be  held  constant. 

Although  fuel  resource  audit  functional  requirements  are  critical 
to  SIMCAT,  accurate  modeling  of  fuel  consumption  rules  does  not  appear 
to  be  sufficiently  important  to  warrant  extensive  development  effort. 

It  appears  sufficient  that  fuel  consumption  be  computed  at  an  approxi¬ 
mate  level.  However,  the  controller/trainer  should  have  the  ability  to 
provide  for  low  fuel  level  conditions  for  various  vehicles  if  he  chooses 
to  initiate  a  simulation  at  less  than  optimal  conditions. 

In  summary,  SIMCAT  must  maintain  a  fuel  resource  audit  for  each 
vehicle  involved  in  a  given  simulation.  This  dictates  that  SIMCAT: 


•  Be  aware  of  the  fuel  level  of  each  vehicle  when  simulation 
is  initiated. 

•  Audit  the  movement  of  each  vehicle  and  time  spent  idling  in 
terms  of  the  amount  of  fuel  expended. 

•  Inform  the  controller/trainer,  appropriate  trainee,  or 
OPFOR  when  a  vehicle  has  exhausted  its  fuel  supply. 

•  Provide  a  record  at  the  conclusion  of  a  simulation  reflect¬ 
ing  the  amount  of  fuel  consumed  and  the  amount  remaining 
for  each  vehicle  in  the  simulation  (necessary  to  provide 
feedback  at  the  conclusion  of  a  simulation). 


Munition  Resource  Audit  Requirements 

In  the  discussion  of  the  engagement  functional  requirements  for 
SIMCAT ,  all  weapon  systems  inherent  in  SIMCAT  and  their  associated  basic 
loads  were  specified.  Given  that  each  weapon  system  Involved  in  a 
SIMCAT  scenario  will  have  been  identified  during  initialization  and  that 
SIMCAT  possesses  a  resident  record  of  the  basic  load  for  each  weapon 
system  (or  a  decreased  basic  load  based  on  controller /trainer  modifica¬ 
tions  made  during  initialization  of  a  simulation) ,  SIMCAT  will  be 
required  to: 

•  Maintain  an  audit  of  the  munition  expenditures  of  each 
weapon  system  (i.e.,  rounds  fired  and  rounds  remaining). 

•  Inform  the  controller/trainer  and  appropriate  trainee  or 
OPFOR  when  a  weapon  system  has  exhausted  a  class  of  muni¬ 
tions  (e.g.,  when  all  HEAT  rounds  in  TCl's  tank  have  been 
exhausted) . 

•  Provide  a  record  at  the  conclusion  of  a  simulation  reflect¬ 
ing  the  amount  and,  if  appropriate,  type  of  munitions 
expended  and  remaining  for  each  weapon  system  in  simulation 
(this  information  is  critical  to  adequate  trainee  feed¬ 
back)  . 


Time 


As  a  battle  simulation,  one  of  the  most  critical  functional  require¬ 
ments  of  SIMCAT  is  the  representation  of  time.  Two  types  of  time  must 
be  represented:  real  time  and  simulation  time.  Each  of  these  will  be 
defined  and  discussed  separately;  information  regarding  the  functional 
requirements  related  to  simulation  time  will  then  follow. 

Real  time  refers  to  the  passing  of  time  in  the  "real  world" 
environment.  It  is  continuous  and  cannot  be  controlled.  It  can  be 
represented  by  a  clock  on  the  wall  and,  in  terms  of  this  discussion,  it 
is  external  to  SIMCAT.  Real  time  relates  solely  to  "real  world" 


considerations;  in  the  case  of  SIMCAT,  these  considerations  relate  to 
such  things  as  when  to  be  off  the  simulator,  when  to  break  for  lunch,  or 
how  long  it  takes  to  complete  a  single  SIMCAT  scenario. 

Simulation  time,  on  the  other  hand,  refers  to  the  passage  of  time 
represented  in  SIMCAT' s  simulated  tactical  environment.  This  passage  of 
time  is  a  critical  factor  to  the  combatants  (l.e.,  OPFOR  and  trainees) 
Involved  in  the  tactical  situation.  In  such  an  environment,  time  is  an 
Important  cue  to  the  existence  or  nonexistence  of  an  expected  event. 

For  example,  given  a  request  for  indirect  fire,  the  requestor  expects 
certain  events  at  certain  times,  such  as  a  shot  and  splash  message  as 
well  as  the  artillery  actually  impacting.  Another  example  would  be  the 
expectation  of  a  platoon  leader  that  the  tanks  In  his  platoon  will  sim¬ 
ultaneously  begin  some  activity  at  a  specific  time.  Given  that  the 
controller/trainer  controls  simulation  time,  OPFOR  and  trainees  can 
easily  lose  track  of  time.  For  example,  if  they  expect  artillery  to 
impact  in  two  minutes  and  the  controller/tralner  stops  the  simulation 
for  five  minutes  and  then  begins  it  again,  from  their  perspective,  did 
the  artillery  impact  three  minutes  ago  or  will  it  impact  in  two  minutes? 

Given  that  SIMCAT  must  provide  all  simulation  positions  (i.e., 
trainees,  OPFOR,  and  controller/tralner)  with  some  perception  of  the 
passage  of  time  within  the  tactical  environment  being  simulated,  certain 
SIMCAT  simulation  time  functional  requirements  have  been  identified. 


Simulation  Time  Requirements 

SIMCAT  is  a  battle  simulation  which  will  be  used  to  conduct 
research  on  how  a  computer  supported  battle  simulation  can  be  used  to 
train  the  command,  control,  and  communication  skills  required  during 
tank  platoon  operations.  As  such,  SIMCAT  must  permit  the  trainer  (or  in 
this  context,  the  controller/trainer)  to  stop  a  simulation  at  any  point 
for  training  purposes  (e.g.,  to  point  out  an  error  made  by  a  trainee) 
and/or  for  administrative  purposes  (e.g.,  to  break  for  lunch).  In 
addition,  the  controller/  trainer  must  have  the  ability  to  replay  all  or 
a  portion  of  a  SIMCAT  simulation.  Normally,  this  will  be  done  at  the 
conclusion  of  a  simulation  to  show  SIMCAT  participants  what  occurred  and 
to  permit  the  controller/tralner  to  review  the  just-completed  simulation 
in  order  to  determine  what  feedback  should  be  provided  to  the  trainees. 

To  satisfy  these  training-related  processes,  there  are  several 
time-control  functional  requirements  SIMCAT  must  satisfy.  Specifically, 
the  controller/trainer  must  be  capable  of: 

*  Specifying  a  specific  simulation  time  he  wishes  to  recall. 

*  Having  accessed  a  specific  simulation  time  (i.e.,  a  point 
In  a  just-completed  simulation  where  the  location  of  all 
friendly  and  OPFOR  vehicles  are  showd  *  accelerating  or 
slowing  down  (l.e.,  decelerating)  the  replay  of  the  simula¬ 
tion  events  (either  forward  or  backward  in  time) . 

*  Stopping  or  freezing  in  place  an  in-process  simulation  or 
replay  of  a  just-completed  simulation. 


•  Determining  the  simulation  time  (as  defined  previously)  in 
either  an  in-progress  simulation  or  a  replay  of  a  just- 
completed  simulation. 

While  a  simulation  is  in  progress,  SIN CAT  must  allow  the  con¬ 
troller/  trainer  to  note  simulation  times  related  to  critical  events  or 
conditions  that  he  may  want  to  recall  at  the  conclusion  of  the  simula¬ 
tion.  This  capability  will  provide  the  controller/trainer  an  easy  and 
expedient  means  of  noting  points  in  the  simulation  (which  may  prove 
critical  to  feedback)  without  disrupting  the  flow  and,  therefore,  the 
fidelity  of  the  simulation.  Given  this  capability,  the  controller/- 
trainer  can  review  a  portion  of  the  just-completed  simulation  not  only 
in  the  context  of  what  occurred  before  the  critical  Incident,  but  in  the 
context  of  events/conditions  that  occurred  afterwards.  The  events/- 
conditions  that  occurred  following  a  critical  point  notation  made  during 
the  simulation  may  render  invalid  the  concerns  that  the  controller/- 
tralner  may  have  had  at  the  time  he  made  the  time  notation.  This 
critical  feature  of  S1HCAT  should  discourage  the  controller/trainer  from 
stopping  an  in-progress  simulation  and  thereby  disrupting  its  flow  and 
fidelity.  Such  a  situation  could  occur,  for  example,  if  a  controller/- 
trainer  were  to  stop  an  in-progress  simulation  to  point  out  that  there 
were  no  tanks  in  overwatch  only  to  find  out,  that  in  fact,  there  were, 
and  he  had  overlooked  that  detail. 


Time  Representation  Requirements 

Simulation  time  can  be  presented  using  an  analog  device  (e.g., 
clock  or  watch  with  hands)  or  a  digital  device  (e.g.,  clock  or  watch 
with  displayed  numbers) .  While  either  approach  can  be  used  to  represent 
time  to  the  S1MCAT  participants,  the  participants  must  be  made  aware  of 
the  following: 

•  The  starting  of  time.  Participants  must  be  made  aware  that 
simulation  time  has  started  (or  restarted  in  the  event  that 
simulation  time  has  been  stopped  by  the  controller/ 
trainer) . 

•  The  passage  of  time.  Participants  must  be  provided  the 
simulation  time  and  be  made  aware  that  simulation  time  is 
passing.  SIMCAT  must  be  capable  of  presenting  simulation 
time  to  the  participants  at  normal,  accelerated,  or  decel¬ 
erated  rates. 

•  The  stopping  of  time.  Participants  must  be  made  aware  that 
simulation  time  has  been  stopped  whenever  the  controller/ 
trainer  decides  to  stop  it. 

•  The  resetting  of  time.  If  the  controller/trainer  decides 
to  reset  simulation  time  to  an  earlier  or  later  point,  the 
participants  must  be  made  aware  of  this  fact  and  oust  be 
shown  the  point  at  which  the  time  has  been  reset. 


Post-S lmulat ion 


SIMCAT  differs  from  a  highly  structured  procedural  or  part-task 
trainer  having  predetermined  conditions,  actions  and  standards. 

Instead,  only  the  initial  conditions  (i.e.,  terrain,  TO&Es  of  two 
opposing  forces,  and  conflicting  missions)  are  set  in  SIMCAT.  As  a 
result,  a  multitude  of  events,  actions,  and  conditions  will  occur  at  a 
very  rapid  rate  during  the  course  of  any  single  SIMCAT  simulation. 

Added  to  this  is  the  fact  that  the  conditions,  events,  actions,  and 
outcomes  of  each  scenario  simulated  in  SIMCAT  will  be  unique,  making  the 
problem  of  "what”  feedback  to  provide  and  "how"  to  provide  it  a  serious 
issue.  These  conditions  dictate  that  SIMCAT  must  provide  the  control¬ 
ler/trainer  access  to  data  in  various  forms  (e.g.,  visual,  audio,  hard 
copy)  from  which  he  can  determine  what  feedback  to  provide  the  trainees 
and  how  to  provide  it.  The  requirements  associated  with  providing  feed¬ 
back  have  been  labeled  post-simulation  functional  requirements. 

Post-simulation  functional  requirements  are  defined  as  the  SIMCAT 
processes  necessary  to  support  the  controller/trainer  responsibility  to 
provide  feedback  to  trainees.  Post-simulation  functional  requirements 
fall  into  three  categories:  visual  playback,  audio  or  communications 
playback,  and  hard  copy  outputs. 


Visual  Playback  Requirements 

One  critical  aspect  of  providing  feedback  related  to  tactical 
environments  is  the  ability  to  reconstruct  events,  actions,  or  condi¬ 
tions.  In  SIMCAT,  each  of  the  positions  involved  will  be  provided  a 
different  perspective  of  events  as  they  occur.  In  addition,  as  the 
Information  processing  capabilities  at  each  position  become  overloaded 
during  a  simulation,  the  ability  of  the  trainee  to  recall  events,  condi¬ 
tions,  or  actions  accurately  will  be  severely  limited.  Therefore, 

SIMCAT  must  have  the  capability  to  record  events,  conditions,  and 
actions  as  they  occur  with  total  accuracy.  This  recall  requirement  of 
SIMCAT,  coupled  with  the  need  to  reconstruct  events,  conditions,  and 
actions,  has  resulted  in  the  identification  of  the  following  visual 
playback  functional  requirements: 

•  The  controller/trainer  must  be  able  to  specify  a  simulation 
time  in  hours  and  minutes  (e.g.,  1  hour,  31  minutes  or  1113 
hours)  and  have  SIMCAT  recall  the  situation  at  that  point 
in  time  in  a  just-completed  or  temporarily  halted  simula¬ 
tion. 

•  Given  a  simulation  time,  the  controller/trainer  must  be 
able  to  specify  which  perspective  he  wishes  to  see  (i.e., 
whatever  was  seen  on  the  display  of  the  controller /trainer , 

OPFOR  or  any  one  of  the  trainees) . 

•  The  controller/trainer  must  be  able  to  display  perspectives 
at  different  SIMCAT  positions  simultaneously.  Suppose,  for 
example,  that  a  controller /trainer  wishes  to  review  a 
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situation  in  which  an  Ml  tank  was  destroyed  by  a  SAGGER. 

To  reconstruct  this  event,  it  would  be  advantageous  to 
display  simultaneously  the  perspective  of  the  control¬ 
ler/trainer  (i.e.,  God's-eye  view  of  all  vehicles 
involved),  the  OPFOR  (i.e.,  what  the  OPFOR  saw  at  the 
time) ,  and  the  trainee  whose  tank  wa6  destroyed.  Accom¬ 
plishing  this,  the  controller /trainer  can  review  the 
situation  from  the  point  of  view  of  each  participant  and 
point  out  what  should  have  happened  (e.g.,  "This  is  what 
the  OPFOR  saw;  you  should  have  detected  him,  and/or  had 
someone  in  overwatch") . 

•  Given  a  simulation  time,  perspective,  and  station 

selection,  the  controller/trainer  must  have  the  ability  to 
move  forward  or  backward  at  either  an  accelerated  or  a 
decelerated  rate. 


Audio  or  Communications  Playback  Requirements 

It  is  understood  that  SIMCAT  will  be  used  for  conducting  research 
on  training  command,  control,  ar.d  communication  in  a  tank  platoon. 
Therefore,  It  is  important  that,  at  the  conclusion  of  a  simulation,  the 
controller/trainer  be  provided  the  ability  to  review  (prior  to  providing 
feedback  to  trainees)  and  reconstruct  (while  providing  feedback  to 
trainees)  communications  which  occurred  during  the  just-completed  or 
temporarily  halted  simulation.  This  need  dictates  that  SIMCAT  record 
any  communication(s)  that  occurred  during  the  simulation  and  provide  the 
controller/trainer  the  ability  to  access  and  recall.  Given  these  con¬ 
troller/  trainer  feedback  requirements,  the  following  audio  or 
communications  post-simulation  functional  requirements  have  been  identi¬ 
fied  : 


•  The  controller/trainer  must  be  able  to  select  the  SIMCAT 
communication  net  he  wishes  to  access  (i.e..  Controller 
Net,  Company  Team  Net,  or  Platoon  Net,  defined  and 
addressed  in  detail  in  the  discussion  of  the  SIMCAT  Com¬ 
munication  Functional  Requirements). 

•  Having  selected  the  communication  net  he  wishes  to  access, 
the  controller/trainer  must  be  able  to  specify  the  simu¬ 
lation  time  (or  point  in  the  net's  recording)  that  he 
wishes  to  access  (  e.g.,  1  hour,  31  minutes).  SIMCAT  must 
then  "turn  back  the  clock"  to  the  point  designated  by  the 
controller/trainer  on  the  communication  net  specified. 


Given  the  communication  net  and  simulation  time,  the  con¬ 
troller/trainer  must  be  provided  the  ability  to  move 
forward  or  backward  from  that  point,  and  to  hear  what  was 
communicated.  He  must  be  able  to  move  forward  or  backward 
at  one  of  three  rates:  real  time,  accelerated  time,  or 
decelerated  time.  It  should  be  noted  that  the  controller/ 
trainer  no  doubt  will  synchronize  visual  playbacks  with 
audio  or  communication  playbacks. 
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•  Given  that  SIMCAT  will  have  more  than  one  communication 
output  channel  (e.g.,  a  "squawk  box"  at  the  controller/ 
trainer  station,  one  for  each  trainee  position),  the 
controller /trainer  must  be  able  to  select  the  communication 
output  channel  on  which  he  wishes  the  communications  to  be 
played.  It  should  also  be  anticipated  that  the  control- 
ler/trainer  may  desire  to  play  back  two  synchronized 
communication  nets  simultaneously. 

Hard  Copy  Output  Requirements 

Although  the  conditions,  events,  actions,  and  outcomes  of  each 
scenario  simulated  in  SIMCAT  will  be  unique,  it  can  be  anticipated  that 
certain  data  may  be  critical  when  providing  feedback  to  the  trainees. 
These  data  requirements  can  be  viewed  as  serving  two  purposes.  First, 
they  will  provide  the  controller/trainer  with  clues  about  both  good  and 
poor  performance.  As  such,  the  data  could  prompt  the  controller/trainer 
to  look  for  additional  information.  Suppose,  for  example,  that  SIMCAT 
provided  the  controller /trainer  with  a  hard  copy  output  outlining  when 
(in  simulation  time)  each  friendly  vehicle  was  destroyed  or  damaged  and 
which  OPFOR  weapon  system  caused  the  destruction  or  damage.  The 
controller/trainer  could  use  these  data  to  identify  the  visual  and  audio 
or  communication  points  (i.e.,  simulation  time)  that  he  should  play  back 
to  determine  what  happened  and  what  feedback,  if  any,  should  be  pro¬ 
vided.  The  predetermined  data  could  also  be  used  in  output  form  as 
direct  feedback  to  the  trainees,  thereby  providing  each  trainee  with  a 
listing  of  the  number,  type,  and  time  he  fired  main  gun  rounds  and  the 
OPFOR  casualties,  if  any,  that  resulted. 

Identifying  and  specifying  post-simulation  hard  copy  output 
requirements  for  SIMCAT  (i.e.,  content  and  format)  normally  requires 
several  analyses  (e.g.,  training  objectives,  possible  events)  and  a 
sequential  development  process.  Given  the  time  constraints  associated 
with  the  development  of  SIMCAT' s  functional  requirements,  however,  the 
procedures  normally  followed  in  Identifying  and  specifying  the  hard  copy 
output  requirements  cannot  be  executed.  Therefore,  the  SIMCAT  hard  copy 
output  functional  requirements  presented  here  should  be  considered  pre¬ 
liminary  and,  as  such,  subject  to  change. 

As  currently  envisioned,  the  post-simulation  hard  copy  outputs  for 
SIMCAT  fall  into  three  categories:  simulation  summary,  individual 

weapon  system  summary,  and  indirect  fire  summary.  Each  of  these  is 
explained  below, 

•  Simulation  Summary  -  This  output  provides  a  complete  sum¬ 
mary  of  a  completed  simulation.  It  is  composed  of  four 
parts:  general  information,  OPFOR  summary,  friendly  force 
summary,  and  a  chronological  list  of  losses.  The  general 
information  part  of  this  output  contains  the  simulation 
time  (i.e.,  duration  of  the  simulated  scenario),  playing 
time  (i.e.,  actual  time  required  to  "play"  the  simulation), 
identification  and  date  of  the  scenario  played,  and  names 
of  the  individuals  responsible  for  each  of  the  SIMCAT 


positions.  The  next  two  parts  provide  a  brief  summary  of 
each  of  the  opposing  forces  (i.e.,  OPFOR  and  friendly 
force),  specifying  the  mission  of  each  force,  amount  of 
indirect  fire  allocated,  beginning  resources,  and  losses  at 
the  conclusion  of  the  simulation.  The  fourth  and  last  part 
of  this  output  contains  a  chronological  listing  of  losses. 
Losses,  in  this  context,  are  defined  as  the  destruction  or 
damaging  of  either  an  OPFOR  or  friendly  force  vehicle. 
Listed  in  the  sequence  they  occurred,  each  loss  is 
specified  in  terms  of  the  simulation  time  at  which  the  loss 
occurred,  the  nature  of  the  loss  (i.e.,  OPFOR  or  friendly 
force  vehicle,  type  of  vehicle,  and  which  vehicle,  e.g., 
PSG's  Tank),  the  cause  of  the  loss  (indirect  fire  or, 
if  the  result  of  a  direct  fire  weapon,  which  vehicle  caused 
the  casualty) ,  and  the  location  of  the  vehicle  when  it  was 
lost  (its  grid  coordinate) .  A  sample  of  this  output  is 
shown  in  Figure  1. 

•  Individual  Weapon  System  Summary  -  This  output  would  be 

produced  for  each  of  the  weapon  systems  involved  in  a  simu¬ 
lation.  Therefore,  for  an  Ml  tank,  two  different  Indi¬ 
vidual  Weapon  System  Summaries  would  be  produced,  i.e.,  one 
each  for  the  tank  main  gun  and  the  coax.  The  heading  of 
this  output  would  identify  the  weapon  system  being  sum¬ 
marized  (e.g.,  Platoon  Leader's  Tank  Main  Gun  Summary)  and, 
in  parentheses,  the  name  of  the  individual  responsible  for 
that  weapon  system  during  the  simulation  (e.g.,  2LT  J.  K. 
Ogus) .  In  addition,  this  output  la  comprised  of  two  parts: 
the  summary  and  the  engagement  record.  In  the  summary 
part,  the  type  and  number  of  rounds  that  the  weapon  system 
started  with  would  be  noted.  This  would  be  followed  by 
identification  of  the  rounds  expended  expressed  in  terms  of 
both  a  percentage  and  number.  The  mean  range  at  which 
targets  were  engaged  with  the  weapon  system  would  then  be 
expressed  in  meters.  A  summary  of  the  effects,  when  using 
each  type  of  round  would  then  be  shown.  This  summary  would 
list  each  target  (e.g.,  BMP)  that  was  hit  using  that  type 
of  round  and  the  actual  effect  (e.g.,  destroyed  or  damaged) 
on  the  target.  Finally,  a  rounds  per  hit  ratio  would  then 
be  computed  and  noted  (e.g.,  1.5  rounds  per  hit).  The 
engagement  record  portion  of  this  output  would  provide  a 
chronological  listing  of  data  related  to  each  time  the 
weapon  being  summarized  was  fired.  Here  the  time  and  type 
of  round  fired  (if  applicable)  as  veil  as  the  location  of 
the  weapon  system  when  the  round  was  fired  (expressed  by  a 
grid  coordinate) ,  the  type  of  target  being  engaged,  range 
of  target  (expressed  in  meters),  and  effect  (e.g.,  missed, 
destroyed),  if  any,  would  be  noted.  The  last  entry  in  the 
engagement  record  would  always  be  either  the  time,  loca¬ 
tion,  and  what  caused  the  weapon  system  being  summarized  to 
be  destroyed,  or  a  notation  that  the  weapon  system  sur¬ 
vived,  Intact,  at  the  time  the  simulation  was  terminated. 

A  sample  of  this  output  is  shown  in  Figure  2. 
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!  I-'igure  1.  Sample  output  of  simulation  summary. 


[  SIMULATION  SUMMARY 

I 

[  SIMULATION  TIME:  1  hr,  36  min  SCENARIO:  //I 

PLAYING  TIME:  2  hrs,  19  min  DATE:  9/15/84 

PARTICIPANTS : 

i  Controller/trainer  -  MSG  G.L.  Smith 

!  OPFOR  -  2LT  D.L.  Jones 

\  PLT  LDR  -  2LT  J.K.  Ogus 

i  PSGT  -  SSG  A.D.  Killer 

|  TCI  -  SGT  A.T.  Jeep 

•  TC2  -  SGT  H.E.  Quick 


OPFOR  Summary 

MISSION:  Hasty  Defense 

INDIRECT  FIRE  ALLOCATION:  50  rounds,  HE,  Quick 

RESOURCES:  3  BMPs  (each  with  4  SAGGER  missiles,  40  rounds  73mm  HEAT) 
1  T72  (40  rounds  HAVAPFSDS) 

LOSSES:  1  BMP  to  Indirect  Fire 

1  T72  to  Ml  Tank  Main  Gun 


Friendly  Force  Summary 

MISSION:  Hasty  Defense 

INDIRECT  FIRE  ALLOCATED:  200  rounds,  HE,  Quick 
RESOURCES:  4  Ml  Abrams  (each  with  33  rounds  of  APFSDS...) 
LOSSES:  2  Ml  Abrams,  both  to  SAGGERS. 


CHRONOLOGICAL  LIST  OF  LOSSES 
OPFOR  FRIENDLY 

TIME  LOSS  LOSS  CAUSED  BY  LOCATION 


0110 

0111 

0131 


T72 


TCI 1 s  Tank 


TCl's  Main  Gun 
BMP  ill,  SAGGER 
Mines 


Grid  123456 
Grid  126459 
Grid  139489 


Figure  2.  Sample  output  of  individual  weapon  system  summary. 


PLATOON  LEADER’S 
TANK  MAIN  GUN  SUMMARY 
(2LT  J.K.  OGUS) 

SUMMARY 

TYPE  ROUND  LOAD  PERCENT  NUMBER  RANGE  EFFECTS  ROUNDS  FOR  HIT 


APFSDS 

33 

10 

3 

900  M 

1  T72 

1.5  rounds 

destroyed 

per  hit 

1  BMP 

damaged 

HEAT 

t 

t 

• 

1 

» 

1 

« 

t 

« 

t 

t 

« 

ENGAGEMENT 

RECORD 

TIME 

ROUND 

LOCATION 

TARGET 

RANGE 

EFFECT 

0115 

APFSDS 

Grid  123456 

T72 

1 f 100  meters 

Missed 

0117 

APFSDS 

Grid  123456 

BMP 

2t0Q0  meters 

Destroyed 

» 

1 

I 

? 

t 

I 

t 

» 

t 

* 

t 

1 

0215  PLT  LDR'S  TANK  DESTROYED  BY  OPFOR  SAGGER  AT  GRID  234567 


•  Indirect  Fire  Utilization  Summary  -  A  summary  of  indirect 
fire  usage  would  be  produced  for  both  the  OPFOR  and 
friendly  forces.  This  output  would  be  composed  of  two 
parts:  the  summary  and  the  utilization  record.  In  the 
summary  part,  a  summary  of  the  indirect  fire  allocated  (by 
fuze  type  and  number  of  rounds)  and  used  (in  terms  of  both 
a  number  and  percentage)  would  be  provided  along  with  their 
effects  (expressed  in  terms  of  type  and  number  of  vehicles 
destroyed  or  damaged) ,  including  ratio  of  rounds  used  to 
targets  hit.  The  second  part  of  this  output  would  provide 
a  detailed  indirect  fire  utilization  record.  Here  a  chron¬ 
ological  listing  of  all  indirect  fire  requests  (whether 
actually  impacted  or  cancelled)  will  be  presented  with 
related  data.  For  each  request,  this  list  will  indicate: 
time  of  request;  time  fire  impacted;  fuze  type;  number  of 
rounds;  location  of  impact  expressed  as  a  grid  coordinate; 
and  effects,  if  any.  A  sample  of  this  output  is  shown  in 
Figure  3. 


Figure  3.  Sample  output  of  indirect  fire  utilization  summary. 


TASK  II:  DETERMINATION  OF  COMPUTER  AND  DEVICE  CHARACTERISTICS 

AND  SYSTEM  SPECIFICATIONS 


The  purpose  of  the  activities  conducted  during  Task  2  was  to  design 
a  computer  supported  battle  simulation  able  to  meet  as  many  of  the 
SIMCAT  functional  requirements  as  possible.  According  to  the  require¬ 
ments  of  the  contract,  two  different  versions  of  SIMCAT  were  to  be 
designed — a  low  cost  version  ($50,000)  and  a  high  cost  ($150,000) 
version. 

The  first  step  in  the  preparation  of  the  system  specifications  was 
to  collect  detailed  information  on  computers  with  8  and  16  bit  proces¬ 
sors  considered  possible  candidates  for  SIMCAT.  As  part  of  this  effort, 
a  review  was  conducted  of  periodicals  devoted  to  computers  and  those 
that  provided  hardware  specification  overviews.  In  addition,  conversa¬ 
tions  were  held  with  computer  specialists,  and  reports  from  previous 
projects  were  reviewed.  When  necessary,  manufacturers  of  computer 
equipment  were  contacted  and  asked  to  provide  literature  describing 
their  systems. 

The  results  of  these  reviews  were  compiled  and  provided  to  ARI . 
Included  were  descriptions  of  51  different  computers  or  computer 
systems.  Contained  in  these  descriptions  was  information  on  memory, 
available  operating  systems,  communications  protocols,  graphics,  net¬ 
working,  and  costs. 

As  this  information  was  being  collected,  sufficient  progress  was 
being  made  in  the  identification  of  the  functional  requirements  for 
SIMCAT  that  it  became  possible  to  identify  certain  computer  character¬ 
istics  that  would  be  required  to  meet  these  requirements.  It  became 
apparent,  for  example,  that  a  multi-user  system  having  only  one 
processor  would  not  be  able  to  handle  the  graphics  and  voice  require¬ 
ments  of  SIMCAT.  Instead,  a  system  with  distributed  processing  (i.e.,  a 
separate  computer  at  each  station)  would  be  required  in  which  several 
processors  would  be  linked  in  a  local  area  network.  This  narrowed  the 
search  to  microcomputers  with  16  bit  processors  that  could  be  linked  in 
this  manner. 

With  the  completion  of  the  initial  draft  of  the  functional  require¬ 
ments  for  SIMCAT,  additional  hardware  requirements  for  SIMCAT  could  be 
identified.  It  was  apparent  that  the  computer  selected  for  SIMCAT  would 
have  to  interface  with  peripherals  providing  voice  recognition,  sound/- 
speech  synthesis,  graphics  processing,  videodisc  control,  and  local  area 
network  interfacing.  Moreover,  the  peripherals  would  have  to  be  avail¬ 
able  as  "off  the  shelf"  products  since  the  developmental  costs  could  not 
be  supported  by  available  funding.  In  addition,  ARI  made  it  known  that 
the  low  cost  version  of  SIMCAT  would  be  selected  for  development  and 
stressed  repeatedly  that  the  system  must  be  extremely  reliable  even  if 
this  requirement  could  only  be  achieved  by  sacrificing  technological 
sophistication.  As  a  consequence,  the  IBM  Personal  Computer  was 
selected  as  the  microcomputer  that  was  most  able  to  be  expanded  to  meet 
all  of  the  requirements  of  SIMCAT  with  the  least  risk. 
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Once  Che  IBM  Personal  Computer  was  selected  for  SIMCAT,  a  detailed 
comparison  was  made  of  the  hardware,  software,  and  peripherals  that  were 
available  for  this  computer.  Performance  comparisons  were  then  made  in 
terms  of  the  final  set  of  functional  requirements  taking  into  account 
the  funds  that  were  available  for  the  purchase  of  the  system  components. 
It  became  apparent  at  this  time  that  certain  critical  requirements  could 
not  be  met  at  the  lower  cost  option.  To  maintain  this  cost  figure  would 
require  giving  up  voice  recognition  and  speech/sound  synthesis.  More¬ 
over,  it  would  require  that  each  SIMCAT  participant  (i.e. ,  all  four 
trainees,  controller/trainer ,  OPFOR)  have  the  same  view  of  the  battle¬ 
field.  However,  since  these  deficiencies  could  be  overcome  for  an 
additional  amount  of  funding,  the  spending  limit  for  the  low  cost  system 
was  increased  to  $60,000.  In  addition,  a  videodisc  map  display  was 
produced  that  would  be  used  for  all  SIMCAT  stations.  The  final  list  of 
components  for  the  low  cost  configuration  of  SIMCAT  are  contained  in 
Table  4. 


Table  4 

SIMCAT  Hardware  and  Software  Configuration 


£ 

Components _  Quantity 


COMMON  TO  ALL  POSITIONS 

IBM  PC  Personal  Computer  with  64K  RAM  6 
512K  200ns  RAM  (with  parity  check)  6 
Tecmar  Graphics  Master  Board  6 
Sony  LDP  1000A  Video  Disc  Player  6 
Sony  12"  High  Res  Color  Monitor  PVM  1270Q  6 
IBM  PC  XT  Power  Supply  6 
JetDrive  RAM  Disk  Driver  6 
Xnet  Expansion  Card  6 

CONTROLLER  STATION 

Streaming  Tape  Backup  System  1 
IBM  Monochrome  Monitor  1 
IBM  Monochrome  Adaptor  and  Parallel  Printer  Card  1 
360KB  Sanyo  Floppy  Disk  Drive  Unit  1 
LNW  BusBoard  w/Floppy  Disk  Controller,  serial  port, 

clock  module  1 
Logitech  Mouse  (Input  Device)  1 
C.  Itoh  Dot  Matrix  Printer  1 


( table  continues) 
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Table  4  (cont'd) 


TANK  COMMANDER  STATIONS 


Hayes  Products  Mach  III  Joystick  4 
Function  Keyboard  4 
1.2MB  Mitsubishi  Floppy  Disk  Drive  4 
360KB  Sanyo  Floppy  Disk  Drive  4 
LNW  BusBoard  w/Floppy  Disk  Controller ,  serial  port,  game  port  4 
Votan  Speech  Recognition/Reproduction  Board  4 

OPFOR  STATION 

1.2  MB  Mitsubishi  Floppy  Disk  Drive  1 
360KB  Sanyo  Floppy  Disk  Drive  1 
LNW  BusBoard  w/Floppy  Disk  Controller,  serial  port  1 
Logitech  Mouse  1 

GENERAL  SYSTEM  REQUIREMENTS 

Miscellaneous  Fabrication  Cables,  and  Equipment  NA 
8087  Numeric  Coprocessor  Chip  1 
Standard  5  1/4"  DS/DD  floppy  disks  20 
Super  High  Density  5  1/3"  DS  floppy  disks  40 
Driver  for  Mitsubishi  Floppy  1 
IBM  PC  64K  RAM,  one  DS/DD  Floppy  Drive  1 
192K  200ns  RAM  (with  parity  check)  1 
External  Syn  Source  and  Distributed  Amplifier  System  1 
Xcomp  31,5MB  Hard  Disk  1 
Xcomp  Expansion  Card  1 
JetDrive  RAM  Disk  Driver  1 
IBM  DOS  2.1  Operating  System  7 
Logi  Tech  Modula2-86  1 
IBM  Technical  Reference  Manual  1 
IBM  DOS  2.1  Technical  Reference  Manual  1 
V-Edit  Text  Editor  1 


aWhlle  specific  products  are  listed,  they  may  be  replaced  by  equivalent 
products  due  to  the  bid  process. 
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